From nobody Mon Jun 2 08:40: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 113F91A0241 for ; Mon, 2 Jun 2014 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 1PfeTtWDsNZr for ; Mon, 2 Jun 2014 08:40:53 -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 4B3141A0232 for ; Mon, 2 Jun 2014 08:40:53 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 6D7262B4522; Mon, 2 Jun 2014 16:40:47 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1C78C2B44CE for ; Mon, 2 Jun 2014 16:40:46 +0100 (BST) Message-ID: <538C9AFD.2010006@erg.abdn.ac.uk> Date: Mon, 02 Jun 2014 16:40:45 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/78rUX1fxcisxeW3qXF2DatBT-e8 Subject: [tsvwg] Request for WG support for Circuit Breakers drfat. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:40:55 -0000 As an individual author, to the WG (and the TSVWG Chairs): I wrote the draft below in response to the large number of side discussions and meeting minutes spent on this topic at the last IETF. I’d be very keen to see (or hear) feedback on this draft, and whether this document could be a reasonable basis for a TSVWG document on this topic. http://tools.ietf.org/html/draft-fairhurst-tsvwg-circuit-breaker-01 Best wishes, Gorry (only as the author of this submission) From nobody Wed Jun 4 04:02: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 9167C1A0359 for ; Wed, 4 Jun 2014 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 KGlmHswDDOlK for ; Wed, 4 Jun 2014 04:02:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612AF1A032F for ; Wed, 4 Jun 2014 04:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2970; q=dns/txt; s=iport; t=1401879752; x=1403089352; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Dm0QTAP08WfafEevaxl4ydGt93e8nNlumpI/fJuc/h4=; b=Cn/7cfuzCQRE9D1KVUAR8tgrIrmmetd6J/RgEmUCHVb5+jGVLNyyiiyS K+x8TWkgDT/cq3Z8b9Muc82NZBYkaVEWW1G5QIKo1MgAS296aOZATsyTH SvKJg/rl6UA3bC/1V/ZqQVdlSnBJxvLikHKws5wHdsmjsifr/gLqwnZ/N M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAGf8jlOtJA2I/2dsb2JhbABZgwdSWIJswAcBGXIWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYg5Daw3pXAXgSqMdzgGgm82gRUEm06Rd4M4bIFD X-IronPort-AV: E=Sophos;i="4.98,972,1392163200"; d="scan'208";a="330437099" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jun 2014 11:02:31 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s54B2U53001364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Jun 2014 11:02:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 06:02:30 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.txt Thread-Index: AQHPf+MyUHdmQIZk4UaV4Ec4CXcVNptgxt4Q Date: Wed, 4 Jun 2014 11:02:30 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.com> References: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> In-Reply-To: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/nle-sUyX2K1G931_VAY_ljD1skw Subject: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.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: Wed, 04 Jun 2014 11:02:42 -0000 SGkgYWxsLA0KDQpUcmF2ZXJzYWwgVXNpbmcgUmVsYXkgTkFUIChUVVJOKSBzZXJ2ZXIgYW5kIHRo ZSBuZXR3b3JrIGluIHdoaWNoIGl0IGlzIGhvc3RlZCBkdWUgdG8gbG9hZCBjb3VsZCBhZHZlcnNl bHkgaW1wYWN0IHRoZSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdC4gIER1cmluZyBzdWNoIGhp Z2ggbG9hZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljIGJ1dCBU VVJOIHNlcnZlciBsYWNrIHJlcXVpcmVtZW50cyBhYm91dCB0aGUgZmxvd3MgdG8gcHJpb3JpdGl6 ZSB0aGVtLiBUaGlzIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmct dHN2d2ctdHVybi1mbG93ZGF0YS0wMCBkZWZpbmVzIGEgbWVjaGFuaXNtIHRvIGNvbW11bmljYXRl IGZsb3cgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIFRVUk4gY2xpZW50IHRvIGl0cyBUVVJOIHNl cnZlci4NCg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0K IA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXks IEp1bmUgMDQsIDIwMTQgNDoyMyBQTQ0KVG86IFJhbSBNb2hhbiBSIChybW9oYW5yKTsgQnJhbmRv biBXaWxsaWFtczsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5n KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5nKTsgUmFtIE1v aGFuIFIgKHJtb2hhbnIpOyBCcmFuZG9uIFdpbGxpYW1zDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2luZy10c3Z3Zy10dXJuLWZsb3dkYXRhLTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVk ZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtd2lu Zy10c3Z3Zy10dXJuLWZsb3dkYXRhDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJVFVSTiBleHRlbnNp b24gdG8gY29udmV5IGZsb3cgY2hhcmFjdGVyaXN0aWNzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA2 LTA0DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbmctdHN2 d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLXRzdndnLXR1cm4tZmxvd2RhdGEvDQpIdG1saXpl ZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy10c3Z3Zy10dXJu LWZsb3dkYXRhLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUVVJOIHNlcnZlciBhbmQgdGhlIG5ldHdv cmsgaW4gd2hpY2ggaXQgaXMgaG9zdGVkIGR1ZSB0byBsb2FkIGNvdWxkDQogICBhZHZlcnNlbHkg aW1wYWN0IHRoZSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdC4gIER1cmluZyBzdWNoIGhpZ2gN CiAgIGxvYWQgZXZlbnQsIGl0IGlzIGRlc2lyYWJsZSB0byBzaGVkIHNvbWUgdHJhZmZpYyBidXQg VFVSTiBzZXJ2ZXIgbGFjaw0KICAgcmVxdWlyZW1lbnRzIGFib3V0IHRoZSBmbG93cyB0byBwcmlv cml0aXplIHRoZW0uICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIHN1Y2ggYSBtZWNoYW5pc20g dG8gY29tbXVuaWNhdGUgZmxvdyBjaGFyYWN0ZXJpc3RpY3MgZnJvbSB0aGUNCiAgIFRVUk4gY2xp ZW50IHRvIGl0cyBUVVJOIHNlcnZlci4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Wed Jun 4 08:52: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 520B11A028D; Wed, 4 Jun 2014 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 Gcu7KmIsP5h0; Wed, 4 Jun 2014 08:52:00 -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 6FEF11A0227; Wed, 4 Jun 2014 08:52:00 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s54FpnBL000372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2014 11:51:50 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s54FpnBL000372 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401897110; bh=gdkKm4Ts34ABjZc6V7vwW71Q1ps=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LAj7stqeo1vDLLvQu3peJr+4aM8YvON1PB5mpUHsWIJiw8Zpzko3Uqh/1Z0YfnJRH lTCzu8Jdsw+XcorcTtsgTpAHXCjWJEoRGmzDqA+Sz8prEMzmeJ2qtzzEBGUVBHMt1v rLf10XnCQHbnOss/fz5ljbkJEyNHehwU1Ewk0OZU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s54FpnBL000372 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 4 Jun 2014 11:51:34 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s54FpX6c004529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 11:51:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Wed, 4 Jun 2014 11:51:33 -0400 From: "Black, David" To: "Tirumaleswar Reddy (tireddy)" , "tsvwg@ietf.org" , "tram@ietf.org" Date: Wed, 4 Jun 2014 11:51:32 -0400 Thread-Topic: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.txt Thread-Index: AQHPf+MyUHdmQIZk4UaV4Ec4CXcVNptgxt4QgABRtEA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD33E4A@MX15A.corp.emc.com> References: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.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="utf-8" Content-Transfer-Encoding: base64 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/2Wx79u3UB2kGh-k4GWd3pmCQ2tI Subject: Re: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.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: Wed, 04 Jun 2014 15:52:04 -0000 UXVlc3Rpb246IFNob3VsZCB0aGlzIGRyYWZ0IGJlIGNvbnNpZGVyZWQgYnkgdGhlIHRzdndnIFdH IG9yIHRoZSB0cmFtIFdHPw0KDQpUaGUgZHJhZnQgbmFtZSBzdWdnZXN0cyB0c3Z3ZywgYnV0IHRy YW0gaXMgdGhlIGZvY3VzIG9mIFRVUk4gYWN0aXZpdHkNCmFuZCAiZXh0ZW5zaW9ucyB0byBUVVJO IGFuZCBTVFVOIiBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0cmFtJ3MgYWN0aXZpdHkuDQoNCkF0 IGEgbWluaW11bSBJIHdvdWxkIHN1Z2dlc3QgdGhlIHRyYW1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0 IGFzIHRoZSBwcmVmZXJyZWQNCmZvcnVtIGZvciBkaXNjdXNzaW9uIG9mIHRoaXMgZHJhZnQgYmVj YXVzZSB0aGF0IGlzIHdoZXJlIFRVUk4gYWN0aXZpdHkgaXMNCmN1cnJlbnRseSBmb2N1c2VkLg0K DQpUaGFua3MsDQotLURhdmlkICh0c3Z3ZyBXRyBjby1jaGFpcikNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gKHRpcmVkZHkpDQo+IFNlbnQ6 IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA3OjAzIEFNDQo+IFRvOiB0c3Z3Z0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBbdHN2d2ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXdpbmctdHN2d2ctdHVybi0NCj4gZmxvd2RhdGEtMDAudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0K PiBUcmF2ZXJzYWwgVXNpbmcgUmVsYXkgTkFUIChUVVJOKSBzZXJ2ZXIgYW5kIHRoZSBuZXR3b3Jr IGluIHdoaWNoIGl0IGlzIGhvc3RlZA0KPiBkdWUgdG8gbG9hZCBjb3VsZCBhZHZlcnNlbHkgaW1w YWN0IHRoZSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdC4gIER1cmluZw0KPiBzdWNoIGhpZ2gg bG9hZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljIGJ1dCBUVVJO IHNlcnZlcg0KPiBsYWNrIHJlcXVpcmVtZW50cyBhYm91dCB0aGUgZmxvd3MgdG8gcHJpb3JpdGl6 ZSB0aGVtLiBUaGlzIGRyYWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdp bmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMCBkZWZpbmVzIGENCj4gbWVjaGFuaXNtIHRvIGNvbW11 bmljYXRlIGZsb3cgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIFRVUk4gY2xpZW50IHRvIGl0cyBU VVJODQo+IHNlcnZlci4NCj4gDQo+IENvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29t ZS4NCj4gDQo+IC1UaXJ1DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA0OjIzIFBNDQo+IFRvOiBSYW0g TW9oYW4gUiAocm1vaGFucik7IEJyYW5kb24gV2lsbGlhbXM7IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7IERhbg0KPiBXaW5nIChkd2luZyk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSk7IERhbiBXaW5nIChkd2luZyk7IFJhbSBNb2hhbiBSDQo+IChybW9oYW5yKTsgQnJhbmRvbiBX aWxsaWFtcw0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdp bmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtd2luZy10c3Z3Zy10dXJuLWZsb3dkYXRhLTAwLnR4dA0KPiBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtd2luZy10c3Z3Zy10 dXJuLWZsb3dkYXRhDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVRVUk4gZXh0ZW5zaW9uIHRv IGNvbnZleSBmbG93IGNoYXJhY3RlcmlzdGljcw0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA2LTA0 DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTENCj4gVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbmct dHN2d2ctdHVybi0NCj4gZmxvd2RhdGEtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLXRzdndnLXR1cm4tDQo+IGZsb3dk YXRhLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt d2luZy10c3Z3Zy10dXJuLWZsb3dkYXRhLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRV Uk4gc2VydmVyIGFuZCB0aGUgbmV0d29yayBpbiB3aGljaCBpdCBpcyBob3N0ZWQgZHVlIHRvIGxv YWQgY291bGQNCj4gICAgYWR2ZXJzZWx5IGltcGFjdCB0aGUgdHJhZmZpYyByZWxheWVkIHRocm91 Z2ggaXQuICBEdXJpbmcgc3VjaCBoaWdoDQo+ICAgIGxvYWQgZXZlbnQsIGl0IGlzIGRlc2lyYWJs ZSB0byBzaGVkIHNvbWUgdHJhZmZpYyBidXQgVFVSTiBzZXJ2ZXIgbGFjaw0KPiAgICByZXF1aXJl bWVudHMgYWJvdXQgdGhlIGZsb3dzIHRvIHByaW9yaXRpemUgdGhlbS4gIFRoaXMgZG9jdW1lbnQN Cj4gICAgZGVmaW5lcyBzdWNoIGEgbWVjaGFuaXNtIHRvIGNvbW11bmljYXRlIGZsb3cgY2hhcmFj dGVyaXN0aWNzIGZyb20gdGhlDQo+ICAgIFRVUk4gY2xpZW50IHRvIGl0cyBUVVJOIHNlcnZlci4N Cj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4g DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jun 4 09:58: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 26A101A02D9; Wed, 4 Jun 2014 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 iA5njZ0uFC-o; Wed, 4 Jun 2014 09:58:28 -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 15B831A0369; Wed, 4 Jun 2014 09:58:22 -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 803B92B40B9; Wed, 4 Jun 2014 17:58:15 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 4 Jun 2014 17:58:15 +0100 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD33E4A@MX15A.corp.emc.com> References: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD33E4A@MX15A.corp.emc.com> Date: Wed, 4 Jun 2014 17:58:15 +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/FVRz3vThL2QzioGrfPEl6_5-KsM Cc: "tsvwg@ietf.org" , "tram@ietf.org" Subject: Re: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.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: Wed, 04 Jun 2014 16:58:30 -0000 As TSVWG Chair: - It is fine to discuss this draft in TSVWG and get a feeling for the flow data and QoS interactions. If anything significant is discovered - then TSVWG is a great place to get that attention. TSVWG'ers - please do look at this draft! Authors please consider this an offer of Agenda time (even if, as my Co-chair David notes, the adopted work may happen to be finished elsewhere) - the main thing at this time is to clearly set out the proposal and get eyes to look at this - our ADs will for sure to advise on the final place for the work to finish. Gorry :-) > > Question: Should this draft be considered by the tsvwg WG or the tram WG? > > The draft name suggests tsvwg, but tram is the focus of TURN activity > and "extensions to TURN and STUN" are within the scope of tram's > activity. > > At a minimum I would suggest the tram@ietf.org mailing list as the > preferred > forum for discussion of this draft because that is where TURN activity is > currently focused. > > Thanks, > --David (tsvwg WG co-chair) > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tirumaleswar >> Reddy >> (tireddy) >> Sent: Wednesday, June 04, 2014 7:03 AM >> To: tsvwg@ietf.org >> Subject: [tsvwg] FW: New Version Notification for >> draft-wing-tsvwg-turn- >> flowdata-00.txt >> >> Hi all, >> >> Traversal Using Relay NAT (TURN) server and the network in which it is >> hosted >> due to load could adversely impact the traffic relayed through it. >> During >> such high load event, it is desirable to shed some traffic but TURN >> server >> lack requirements about the flows to prioritize them. This draft >> http://tools.ietf.org/html/draft-wing-tsvwg-turn-flowdata-00 defines a >> mechanism to communicate flow characteristics from the TURN client to >> its TURN >> server. >> >> Comments and suggestions are welcome. >> >> -Tiru >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 04, 2014 4:23 PM >> To: Ram Mohan R (rmohanr); Brandon Williams; Tirumaleswar Reddy >> (tireddy); Dan >> Wing (dwing); Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Ram Mohan >> R >> (rmohanr); Brandon Williams >> Subject: New Version Notification for >> draft-wing-tsvwg-turn-flowdata-00.txt >> >> >> A new version of I-D, draft-wing-tsvwg-turn-flowdata-00.txt >> has been successfully submitted by Tirumaleswar Reddy and posted to the >> IETF >> repository. >> >> Name: draft-wing-tsvwg-turn-flowdata >> Revision: 00 >> Title: TURN extension to convey flow characteristics >> Document date: 2014-06-04 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-wing-tsvwg-turn- >> flowdata-00.txt >> Status: https://datatracker.ietf.org/doc/draft-wing-tsvwg-turn- >> flowdata/ >> Htmlized: >> http://tools.ietf.org/html/draft-wing-tsvwg-turn-flowdata-00 >> >> >> Abstract: >> TURN server and the network in which it is hosted due to load could >> adversely impact the traffic relayed through it. During such high >> load event, it is desirable to shed some traffic but TURN server >> lack >> requirements about the flows to prioritize them. This document >> defines such a mechanism to communicate flow characteristics from >> the >> TURN client to its TURN server. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > From nobody Wed Jun 4 20:16:49 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 2AD871A0406; Wed, 4 Jun 2014 20:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 jtpR1vbgq_K0; Wed, 4 Jun 2014 20:16:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA131A0409; Wed, 4 Jun 2014 20:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4854; q=dns/txt; s=iport; t=1401938194; x=1403147794; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=pVGqo+PikiYQhxFz/LuY2PTJLHBheh4EviNLqy1PY6E=; b=ImMo93+rsH1AVd0wavf/5neXpmh3XAT+swuw/1OlhIyZ7zeLj2MT05hj 6aNLYNS1GEuBxgMI23eYWhHrFPK1YPjmWOY7laecf7RFiUV4FvQaqOoDc /LxPc9+viIxVWaE+SOABowDIyyZS2rRPm5IsAP4x1FZOIyoOBbpFO0/Zn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIPgj1OtJA2K/2dsb2JhbABZgwdSWIJswBABGXMWdIIlAQEBAwEjEToJDgYBCBEEAQEDAgYdAwIEMBQBBwEJAQQBEggBiDEIDaxtpWkXgSqMdz6CbzaBFQSbUpF6gXiBQIIv X-IronPort-AV: E=Sophos;i="4.98,977,1392163200"; d="scan'208";a="330708154" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jun 2014 03:16:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s553GXWV015808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 03:16:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 22:16:33 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Black, David" , "tsvwg@ietf.org" , "tram@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.txt Thread-Index: Ac+AbIsvygIpPj7WTI6V1Y1abQyLAg== Date: Thu, 5 Jun 2014 03:16:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C856D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mkE8Hf7DqdqKrIXbDNl5qyv6yf8 Subject: Re: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.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: Thu, 05 Jun 2014 03:16:46 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCbGFjaywgRGF2aWQgW21haWx0 bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQg OToyMiBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHN2d2dAaWV0Zi5v cmc7IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFt0c3Z3Z10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2luZy10c3Z3Zy10dXJuLQ0KPiBmbG93ZGF0YS0wMC50 eHQNCj4gDQo+IFF1ZXN0aW9uOiBTaG91bGQgdGhpcyBkcmFmdCBiZSBjb25zaWRlcmVkIGJ5IHRo ZSB0c3Z3ZyBXRyBvciB0aGUgdHJhbSBXRz8NCg0KUHJpb3IgdG8gcHVibGljYXRpb24gb2YgdGhl IGRyYWZ0LCB3ZSBoYWQgY29uc3VsdGVkIHdpdGggVFJBTSBXRyBjaGFpcnMgd2hvIGFza2VkIHRo ZSBBRCBmb3IgYWR2aWNlIGFuZCB0aGUgZGVjaXNpb24gd2FzIHRvIHB1Ymxpc2ggdGhpcyBkcmFm dCBpbiB0c3Z3Zy4NCg0KLVRpcnUNCg0KPiANCj4gVGhlIGRyYWZ0IG5hbWUgc3VnZ2VzdHMgdHN2 d2csIGJ1dCB0cmFtIGlzIHRoZSBmb2N1cyBvZiBUVVJOIGFjdGl2aXR5IGFuZA0KPiAiZXh0ZW5z aW9ucyB0byBUVVJOIGFuZCBTVFVOIiBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0cmFtJ3MgYWN0 aXZpdHkuDQo+IA0KPiBBdCBhIG1pbmltdW0gSSB3b3VsZCBzdWdnZXN0IHRoZSB0cmFtQGlldGYu b3JnIG1haWxpbmcgbGlzdCBhcyB0aGUgcHJlZmVycmVkDQo+IGZvcnVtIGZvciBkaXNjdXNzaW9u IG9mIHRoaXMgZHJhZnQgYmVjYXVzZSB0aGF0IGlzIHdoZXJlIFRVUk4gYWN0aXZpdHkgaXMNCj4g Y3VycmVudGx5IGZvY3VzZWQuDQo+IA0KPiBUaGFua3MsDQo+IC0tRGF2aWQgKHRzdndnIFdHIGNv LWNoYWlyKQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHRz dndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpcnVtYWxl c3dhcg0KPiA+IFJlZGR5DQo+ID4gKHRpcmVkZHkpDQo+ID4gU2VudDogV2VkbmVzZGF5LCBKdW5l IDA0LCAyMDE0IDc6MDMgQU0NCj4gPiBUbzogdHN2d2dAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBb dHN2d2ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtd2luZy10 c3Z3Zy10dXJuLSBmbG93ZGF0YS0wMC50eHQNCj4gPg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFRy YXZlcnNhbCBVc2luZyBSZWxheSBOQVQgKFRVUk4pIHNlcnZlciBhbmQgdGhlIG5ldHdvcmsgaW4g d2hpY2ggaXQgaXMNCj4gPiBob3N0ZWQgZHVlIHRvIGxvYWQgY291bGQgYWR2ZXJzZWx5IGltcGFj dCB0aGUgdHJhZmZpYyByZWxheWVkIHRocm91Z2gNCj4gPiBpdC4gIER1cmluZyBzdWNoIGhpZ2gg bG9hZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljDQo+ID4gYnV0 IFRVUk4gc2VydmVyIGxhY2sgcmVxdWlyZW1lbnRzIGFib3V0IHRoZSBmbG93cyB0byBwcmlvcml0 aXplIHRoZW0uDQo+ID4gVGhpcyBkcmFmdA0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMCBkZWZpbmVzIGENCj4gPiBtZWNoYW5p c20gdG8gY29tbXVuaWNhdGUgZmxvdyBjaGFyYWN0ZXJpc3RpY3MgZnJvbSB0aGUgVFVSTiBjbGll bnQgdG8NCj4gPiBpdHMgVFVSTiBzZXJ2ZXIuDQo+ID4NCj4gPiBDb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMgYXJlIHdlbGNvbWUuDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0 LCAyMDE0IDQ6MjMgUE0NCj4gPiBUbzogUmFtIE1vaGFuIFIgKHJtb2hhbnIpOyBCcmFuZG9uIFdp bGxpYW1zOyBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiAodGlyZWRkeSk7IERhbiBXaW5nIChkd2lu Zyk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IERhbiBXaW5nDQo+ID4gKGR3aW5nKTsg UmFtIE1vaGFuIFIgKHJtb2hhbnIpOyBCcmFuZG9uIFdpbGxpYW1zDQo+ID4gU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93 ZGF0YS0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdp bmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNCj4gPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvDQo+ID4gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC13aW5nLXRzdndnLXR1cm4tZmxv d2RhdGENCj4gPiBSZXZpc2lvbjoJMDANCj4gPiBUaXRsZToJCVRVUk4gZXh0ZW5zaW9uIHRvIGNv bnZleSBmbG93IGNoYXJhY3RlcmlzdGljcw0KPiA+IERvY3VtZW50IGRhdGU6CTIwMTQtMDYtMDQN Cj4gPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOgkJMTENCj4gPiBV Ukw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt d2luZy10c3Z3Zy10dXJuLQ0KPiA+IGZsb3dkYXRhLTAwLnR4dA0KPiA+IFN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLXRzdndnLXR1cm4t DQo+ID4gZmxvd2RhdGEvDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMA0KPiA+DQo+ID4NCj4gPiBB YnN0cmFjdDoNCj4gPiAgICBUVVJOIHNlcnZlciBhbmQgdGhlIG5ldHdvcmsgaW4gd2hpY2ggaXQg aXMgaG9zdGVkIGR1ZSB0byBsb2FkIGNvdWxkDQo+ID4gICAgYWR2ZXJzZWx5IGltcGFjdCB0aGUg dHJhZmZpYyByZWxheWVkIHRocm91Z2ggaXQuICBEdXJpbmcgc3VjaCBoaWdoDQo+ID4gICAgbG9h ZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljIGJ1dCBUVVJOIHNl cnZlciBsYWNrDQo+ID4gICAgcmVxdWlyZW1lbnRzIGFib3V0IHRoZSBmbG93cyB0byBwcmlvcml0 aXplIHRoZW0uICBUaGlzIGRvY3VtZW50DQo+ID4gICAgZGVmaW5lcyBzdWNoIGEgbWVjaGFuaXNt IHRvIGNvbW11bmljYXRlIGZsb3cgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlDQo+ID4gICAgVFVS TiBjbGllbnQgdG8gaXRzIFRVUk4gc2VydmVyLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From nobody Thu Jun 5 03:56: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 49A741A0195 for ; Thu, 5 Jun 2014 03:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 URrLWoexXGWl for ; Thu, 5 Jun 2014 03:56:37 -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 10F381A0191 for ; Thu, 5 Jun 2014 03:56:37 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id D99CF2B4257; Thu, 5 Jun 2014 11:56:29 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id EFDD02B41EA for ; Thu, 5 Jun 2014 11:56:26 +0100 (BST) Message-ID: <53904CDA.5020902@erg.abdn.ac.uk> Date: Thu, 05 Jun 2014 11:56:26 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/kZd4ptYQ_OdGGlPWjRjS2xRirio Subject: [tsvwg] Updated TSVWG Status 5th June 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:56:40 -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. Please also ensure the chairs are aware of any intended new submissions. Gorry, David & James (TSVWG Chairs) June 2014 ------------------------------------------------------------------- Recently published: None ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry ------------------------------------------------------------------- IDs in IESG processing: None ------------------------------------------------------------------- New proposed work: draft-eggert-tsvwg-rfc5405bis (to be submitted) draft-fairhurst-tsvwg-circuit-breaker (adoption request on tsvwg list) draft-wing-tsvwg-turn-flowdata-00.txt (to be discussed, Toronto). ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James/David Replaces: draft-karagiannis-pcn-tsvwg-rsvp-pcn AD decision allowed this to be added to the milestones 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. Chairs: Write-Up needed (last update February 14, 2014) - David will do. --- 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. ------------------------------------------------------------------- WG Drafts --- 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 Revised ID May 2014. DUE: MILESTONE PASSED, WGLC due. DUE: Waiting for final version from Authors - Reviewers needed to read (e.g. those who want this!!!) --- 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. ++ Eric Rescorla has committed to review this. DUE: A security review during WGLC of next revision. ++ Comments from Joe Touch (draft to be updated) DUE: MILESTONE PASSED DUE: Waiting for final version from Authors DUE: Please comment on list. --- 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) Chairs: - authors have requested 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 in the period up to July 2014. --- 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 DUE: Chairs to consider if combining two IDs would simplify the document --- 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, Chairs to consider if PS status is appropriate 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 for 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. DART draft will need to be in good shape (WGLC?) 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. --- 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 ------------------------------------------------------------------- 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'. DUE: Please comment on list. --- ------------------------------------------------------------------- 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. DUE: Revised ID to set scope required. --- draft-eggert-tsvwg-rfc5405bis (To be submitted) - 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. The authors of both drafts agreed to progress this work. NOTE: Update milestone in charter, if adopted: ‘Multicast UDP Guidelines’ is being incorporated in this. DUE: Initial draft required --- draft-fairhurst-tsvwg-circuit-breaker - Individual (Gorry Fairhurst) Call for adoption issued - June 2014 DUE: Please comment on list --- draft-wing-tsvwg-turn-flowdata-00.txt - Individual - To be discussed in Toronto (thought to also be relevant to TURN WG) ---- From nobody Thu Jun 5 04:05: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 A19B31A043C for ; Thu, 5 Jun 2014 04:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 9xuqnKoXZLjH for ; Thu, 5 Jun 2014 04:05:03 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E9F1A0379 for ; Thu, 5 Jun 2014 04:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=323; q=dns/txt; s=iport; t=1401966297; x=1403175897; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b0cYSiO797ufbBe7u5i2Ok+/Ud2Lw8Yxn1w8EE1IFv8=; b=Wv02G853E34PnYJ4vCEJPB1b4z0HWlS73U9mZKMSY2Rvf28wD3imbmlT jSjyv0ZiNU/XHjLqX8NCJ99FgG1lLEzXd1OekZIBapkAIxACnnX3YKpqs 9BJOgs2ujida9kVrk0Yyoq035Xw3QxNPG0g9eiuoRh2x1jPS0Hf9Jcezc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAIJNkFOtJssW/2dsb2JhbABZDocPwA8BgSN0giUBAQEEI0gNARALGAICBRYEBwICCQMCAQIBRQYBDAEHAQGIPq04phoXgSqNKAeCdYFLAQOaE5M5gXiBAEI7 X-IronPort-AV: E=Sophos;i="4.98,980,1392163200"; d="scan'208";a="70645695" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 05 Jun 2014 11:04:55 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.171.203]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s55B4teX023182; Thu, 5 Jun 2014 11:04:55 GMT Message-ID: <53904ED7.1080400@cisco.com> Date: Thu, 05 Jun 2014 13:04:55 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <53851C9E.8060002@isi.edu> In-Reply-To: <53851C9E.8060002@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/UH_JthV2aS28uUdFKYETqH5wYq4 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) 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, 05 Jun 2014 11:05:05 -0000 On 5/28/14, 1:15 AM, Joe Touch wrote: > > Note that we didn't actively change anything when RFC 6335 was > published; it was not used to justify recommending declining requests. Although as an expert reviewer- I am now basing my logic on that content, and especially as relates to proprietary protocols. Eliot From nobody Sun Jun 8 19:50:54 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 D00D11B27BA; Sun, 8 Jun 2014 19:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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.651, 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 Xr2tBPJ0-eaP; Sun, 8 Jun 2014 19:50:50 -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 A0BD61B27B0; Sun, 8 Jun 2014 19:50:49 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s592olvt001220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jun 2014 22:50:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s592olvt001220 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402282247; bh=5Ou/fjE/v//kPIVTFGuitxVxkw4=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=S2hUEbD/OexQewDLIaAcwro3Om92ZAi+WfaWuTVhRIEJpzUCTZzv4IAcuxu1hvYaL d7IOjKQYhvbRO8eXhMLwV2Ui7XXxPcR/LPC1ymYZ9WwCs0JCn1OZEZ8Awbjv+MmVC1 xNMrc9SbZZkCJHsLdBWCUFyMwEWH/mDHUCijh7eI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s592olvt001220 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Sun, 8 Jun 2014 22:50:30 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s592oU6d005715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jun 2014 22:50:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Sun, 8 Jun 2014 22:50:29 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "tsv-area@ietf.org" Date: Sun, 8 Jun 2014 22:50:28 -0400 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAGh4wIA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD34339@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@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: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/2gu47W8Hq14Rlz70sPX8pOct2Ak Subject: [tsvwg] FW: I-D Action: draft-york-dart-dscp-rtp-00.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, 09 Jun 2014 02:50:53 -0000 Initial -00 draft for dart has appeared. FYI, --David -----Original Message----- From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Black, David Sent: Friday, June 06, 2014 9:05 PM To: dart@ietf.org Subject: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt On behalf of the author team, here's an initial -00 draft for consideration by the dart WG. Please keep in mind that this is a -00 draft, so it really is a "draft". I should be embarrassed that it appeared to take a public nudge from a past IETF Chair (Harald) to get this draft to appear, (Aside: if you'd like that ability, send your name to the NomCom this year - they're always looking for interested candidates for all positions), but the fact of the matter is that more than one of us had the experience of life being what happens while one is busy making other plans. Comments and feedback are welcome and encouraged. Thanks, --David ---------------------------------------------------- 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 ---------------------------------------------------- -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, June 06, 2014 8:49 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Differentiated Services (DiffServ) and Real-time = Communication Authors : Dan York David Black Cullen Jennings Paul Jones Filename : draft-york-dart-dscp-rtp-00.txt Pages : 13 Date : 2014-06-06 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). As a result, use of different DSCPs within a single traffic flow may cause transport protocol interactions (e.g., due to reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including RTCWEB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Sun Jun 8 19:56: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 4D3E01B27B0; Sun, 8 Jun 2014 19:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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.651, 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 3Tad_B7kmmrC; Sun, 8 Jun 2014 19:56:15 -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 8FB8D1B27BD; Sun, 8 Jun 2014 19:56:15 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s592uE2J002451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jun 2014 22:56:14 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s592uE2J002451 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402282574; bh=q4KXgTMgwHcKfNGKn81dUuRZe0k=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YsvEVqfr3lQnaqJpWCDdKaHq//zTbGf2pqn3LSO0rBIQD+KOuA7SrRyMkTvY7T8yh JLAXsizWOSYHcB3yQV4yV00059qn22+G4qsmsEMNHx0nW2gN9Ywu+QscVQlT52JQhD Idh59RGgXs0YfDgMZ9Dc0h38rSDKs/MwDZkIaQJ0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s592uE2J002451 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd04.lss.emc.com (RSA Interceptor); Sun, 8 Jun 2014 19:55:56 -0700 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s592ttlw015905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jun 2014 22:55:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Sun, 8 Jun 2014 22:55:55 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "tsv-area@ietf.org" Date: Sun, 8 Jun 2014 22:55:54 -0400 Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAGh4wIAAADQQwA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD3433C@MX15A.corp.emc.com> References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076FD34339@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD34339@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: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jUn5VAeOFxjtGxJmct-KfDr4rsA Subject: Re: [tsvwg] I-D Action: draft-york-dart-dscp-rtp-00.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, 09 Jun 2014 02:56:18 -0000 And discussion should be on the dart@ietf.org list, please. Thanks, --Davi= d > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Sunday, June 08, 2014 10:50 PM > To: tsvwg@ietf.org; tsv-area@ietf.org > Subject: [tsvwg] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > Initial -00 draft for dart has appeared. FYI, --David >=20 > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, June 06, 2014 9:05 PM > To: dart@ietf.org > Subject: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 > On behalf of the author team, here's an initial -00 draft for > consideration by the dart WG. Please keep in mind that this is a -00 > draft, so it really is a "draft". >=20 > I should be embarrassed that it appeared to take a public nudge from a > past IETF Chair (Harald) to get this draft to appear, (Aside: if you'd > like that ability, send your name to the NomCom this year - they're > always looking for interested candidates for all positions), but the > fact of the matter is that more than one of us had the experience of > life being what happens while one is busy making other plans. >=20 > Comments and feedback are welcome and encouraged. >=20 > Thanks, > --David > ---------------------------------------------------- > 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 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and Real-tim= e > Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic flow may cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Tue Jun 10 01:38: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 B2FFF1A0329; Tue, 10 Jun 2014 01:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 MDeAaI0g9iCF; Tue, 10 Jun 2014 01:38:44 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54CE1A0291; Tue, 10 Jun 2014 01:38:43 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s5A8ca37026081; Tue, 10 Jun 2014 10:38:36 +0200 From: "Jose Saldana" To: Date: Tue, 10 Jun 2014 10:38:42 +0200 Message-ID: <014d01cf8487$62adea50$2809bef0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014E_01CF8498.26386800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+Eh2GI8HW2AgRVTj+g1lvK0tUNGA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/zKR4d4D0PrfhVCbtBZMIWje0aE0 Cc: Martin Stiemerling , tsv-area@ietf.org, tsvwg@ietf.org Subject: [tsvwg] New version (v7) of TCM-TF draft 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, 10 Jun 2014 08:38:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014E_01CF8498.26386800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all. A new version (v7) of the main TCM-TF draft has been submitted to the IETF web page. http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model, draft-saldana-tsvwg-tcmtf-07 Some of the improvements are: - Stating that TCM-TF must keep backwards compatibility with RFC4170. Some people suggested it on the last BoF, because some devices already implement it. - Adding some new information about Community Networks. - Adding the possibility of optimizing UDP traffic of Constrained RESTful Environments (http://datatracker.ietf.org/wg/core/). - Adding three new references. - Slightly improving some figures. Your comments will be welcome. Best regards, Jose Saldana ----------------------------------------- A new version of I-D, draft-saldana-tsvwg-tcmtf-07.txt has been successfully submitted by Jose Saldana and posted to the IETF repository. Name: draft-saldana-tsvwg-tcmtf Revision: 07 Title: Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model Document date: 2014-06-10 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-tcmtf-07.txt Status: https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Htmlized: http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-tcmtf-07 Abstract: Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a method for improving the bandwidth utilization of network segments that carry multiple flows in parallel sharing a common path. The method combines standard protocols for header compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth. The amount of packets per second can also be reduced. This document describes the TCM-TF framework and the different options which can be used for each layer (header compression, multiplexing and tunneling). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------=_NextPart_000_014E_01CF8498.26386800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all.

 

A new version (v7) of = the main TCM-TF draft has been submitted to the IETF web = page.

 

http:= //datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

Tunneling Compressed = Multiplexed Traffic Flows (TCM-TF) Reference Model, = draft-saldana-tsvwg-tcmtf-07

 

 

Some of the = improvements are:

 

- Stating that TCM-TF = must keep backwards compatibility with RFC4170. Some people suggested it = on the last BoF, because some devices = already implement it.

- Adding some new = information about Community Networks.

- Adding the = possibility of optimizing UDP traffic of Constrained RESTful Environments (http://datatracker.ietf.org= /wg/core/).

- Adding three new = references.

- Slightly improving = some figures.

 

Your comments will be = welcome.

 

Best = regards,

 

Jose Saldana

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

A new version of I-D, = draft-saldana-tsvwg-tcmtf-07.txt has been successfully submitted by Jose = Saldana and posted to the IETF repository.

 

Name:        = ;     draft-saldana-tsvwg-tcmtf

Revision:        = ; 07

Title:        = ;        Tunneling Compressed = Multiplexed Traffic Flows (TCM-TF) Reference = Model

Document date:        = ; 2014-06-10

Group:        = ;     Individual = Submission

Pages:        = ;            =     26

URL:       &nbs= p;    http://www.ietf.org/internet-drafts/dra= ft-saldana-tsvwg-tcmtf-07.txt

Status:       &nbs= p; https://datatracker.ietf.org/doc/draft-= saldana-tsvwg-tcmtf/

Htmlized:       = http://tools.ietf.org/html/draft-saldan= a-tsvwg-tcmtf-07

Diff:       &nbs= p;   = http://www.ietf.org/rfcdiff?url2=3Ddraf= t-saldana-tsvwg-tcmtf-07

 

Abstract:

   Tunneling Compressed and = Multiplexed Traffic Flows (TCM-TF) is a

   method for improving the = bandwidth utilization of network segments

   that carry multiple flows = in parallel sharing a common path.  The

   method combines standard = protocols for header compression,

   multiplexing, and = tunneling over a network path for the purpose of

   reducing the = bandwidth.  The amount of = packets per second can also be

   = reduced.

 

   This document describes = the TCM-TF framework and the different

   options which can be used = for each layer (header compression,

   multiplexing and = tunneling).

 

       &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;

 

 

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

 

The IETF Secretariat

 

 

------=_NextPart_000_014E_01CF8498.26386800-- From nobody Tue Jun 10 01:59:29 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 04A311A02BA; Tue, 10 Jun 2014 01:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rlHgYvAKUXT; Tue, 10 Jun 2014 01:59:27 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3406C1A0166; Tue, 10 Jun 2014 01:59:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,1008,1392192000"; d="asc'?scan'208";a="169260888" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 10 Jun 2014 01:59:27 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 01:59:26 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 10 Jun 2014 01:59:26 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::8485:306a:80a6:ba8f%21]) with mapi id 15.00.0847.030; Tue, 10 Jun 2014 01:59:26 -0700 From: "Eggert, Lars" To: Jose Saldana Thread-Topic: [tsvwg] New version (v7) of TCM-TF draft Thread-Index: Ac+Eh2GI8HW2AgRVTj+g1lvK0tUNGAAPZFUA Date: Tue, 10 Jun 2014 08:59:25 +0000 Message-ID: <2066ADBD-A397-4A34-AC40-4413347DB6B3@netapp.com> References: <014d01cf8487$62adea50$2809bef0$@unizar.es> In-Reply-To: <014d01cf8487$62adea50$2809bef0$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_5313AF05-64CC-42B2-B739-9BF96EE40E7D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/YxkH8Y0vog0fRI-BvDtz-koHzdc Cc: "tcmtf@ietf.org" , Martin Stiemerling , "tsv-area@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] New version (v7) of TCM-TF draft 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, 10 Jun 2014 08:59:28 -0000 --Apple-Mail=_5313AF05-64CC-42B2-B739-9BF96EE40E7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, are there any measurements or simulations that would quantify the = benefits (in terms of bandwidth) and drawbacks (in terms of latency)? Lars --Apple-Mail=_5313AF05-64CC-42B2-B739-9BF96EE40E7D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU5bI7NZcnpRveo1xAQKwgwP5AQqstlPp/RjFv/Ie2W7ByKXCsN3qO4SN 5fzT29joXqCGsdDfOwB6AOi1f08b2oeqxFgzOG1DA+ASg5NIgY+bV4mzp1VoAvIw bADDFHhLJPjiX4BAwtLhHpZJjUee848JVpGrxY/MKwegch55PCA01T+qi2Q4c+Dd ez0b3IrMh/I= =Idt8 -----END PGP SIGNATURE----- --Apple-Mail=_5313AF05-64CC-42B2-B739-9BF96EE40E7D-- From nobody Tue Jun 10 04:02: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 CB7B41A0535; Tue, 10 Jun 2014 04:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 9M1OA3upAZpK; Tue, 10 Jun 2014 04:02:05 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C281A050E; Tue, 10 Jun 2014 04:02:04 -0700 (PDT) Received: from [127.0.0.1] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s5AB1xHv020719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Jun 2014 13:01:59 +0200 Message-ID: <5396E5A4.6090508@unizar.es> Date: Tue, 10 Jun 2014 13:01:56 +0200 From: =?ISO-8859-15?Q?Juli=E1n_Fern=E1ndez-Navajas?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eggert, Lars" , Jose Saldana References: <014d01cf8487$62adea50$2809bef0$@unizar.es> <2066ADBD-A397-4A34-AC40-4413347DB6B3@netapp.com> In-Reply-To: <2066ADBD-A397-4A34-AC40-4413347DB6B3@netapp.com> Content-Type: multipart/alternative; boundary="------------030909020708070809010902" X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/QJL6jc-u9VfrKo9JbnSucwU6amc Cc: "tcmtf@ietf.org" , Martin Stiemerling , "tsv-area@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] New version (v7) of TCM-TF draft 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, 10 Jun 2014 11:02:08 -0000 This is a multi-part message in MIME format. --------------030909020708070809010902 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Hello Lars, I send you some publications that quantify the benefits (in terms of bandwidth) and drawbacks (in terms of latency and loss). VoIP: this paper evaluates the bandwidth savings and also the influence of multiplexing on VoIP subjective quality (using ITU's E-Model): /"Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP Conversation Quality ,"/Computer Networks (Elsevier), Volume 56, Issue 7, Pages 1893-1919, May2012.doi __10.1016/j.comnet.2012.02.004 Online games: This paper also calculates bandwidth savings: /_First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?_,"IEEE Communications Magazine,vol. 49, no.11, pp. 190-198,November 2011. doi:_10.1109/MCOM.2011.6069728_/ And this one is focused on the effect on subjective quality (using a subjective quality estimator for a FPS game): /"Online FPS Games: Effect of Router Buffer and Multiplexing Techniques on Subjective Quality Estimators,"_Multimedia Tools and Applications_, Springer._doi__10.1007/s11042-012-1309-4_/ Regards Julián El 10/06/2014 10:59, Eggert, Lars escribió: > Hi, > > are there any measurements or simulations that would quantify the benefits (in terms of bandwidth) and drawbacks (in terms of latency)? > > Lars --------------030909020708070809010902 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
Hello Lars,

I send you some publications that quantify the benefits (in terms of bandwidth) and drawbacks (in terms of latency and loss).

VoIP: this paper evaluates the bandwidth savings and also the influence of multiplexing on VoIP subjective quality (using ITU’s E-Model):

"Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP Conversation Quality," Computer Networks (Elsevier), Volume 56, Issue 7, Pages 1893-1919, May 2012. doi 10.1016/j.comnet.2012.02.004

 

Online games: This paper also calculates bandwidth savings:

First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, vol. 49, no.11, pp. 190-198, November 2011. doi: 10.1109/MCOM.2011.6069728

 

And this one is focused on the effect on subjective quality (using a subjective quality estimator for a FPS game):

"Online FPS Games: Effect of Router Buffer and Multiplexing Techniques on Subjective Quality Estimators," Multimedia Tools and Applications, Springer. doi 10.1007/s11042-012-1309-4

 

Regards

Julián


 El 10/06/2014 10:59, Eggert, Lars escribió:
Hi,

are there any measurements or simulations that would quantify the benefits (in terms of bandwidth) and drawbacks (in terms of latency)?

Lars

--------------030909020708070809010902-- From nobody Tue Jun 10 07:23: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 8AD161A0162; Tue, 10 Jun 2014 07:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 EPK2vhXNV7h5; Tue, 10 Jun 2014 07:23:49 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879071A0641; Tue, 10 Jun 2014 07:23:48 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s5AENZWQ031529; Tue, 10 Jun 2014 16:23:35 +0200 From: "Jose Saldana" To: "=?iso-8859-1?Q?'Juli=E1n_Fern=E1ndez-Navajas'?=" , "'Eggert, Lars'" References: <014d01cf8487$62adea50$2809bef0$@unizar.es> <2066ADBD-A397-4A34-AC40-4413347DB6B3@netapp.com> <5396E5A4.6090508@unizar.es> In-Reply-To: <5396E5A4.6090508@unizar.es> Date: Tue, 10 Jun 2014 16:23:43 +0200 Message-ID: <017a01cf84b7$9599cd00$c0cd6700$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01CF84C8.592471C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE96092ijokgBxLOjv2xa9rtUjGDQHIKuVXAhOfxE2cbrNtoA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/WL6rmXY4DuIYNKBc0T6KQ7F-wEc Cc: tcmtf@ietf.org, 'Martin Stiemerling' , tsv-area@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] New version (v7) of TCM-TF draft 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, 10 Jun 2014 14:23:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017B_01CF84C8.592471C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Juli=E1n. =20 Just a brief summary: =20 a) VoIP - The bandwidth savings for VoIP could be up to 57%, if RTP and G729a = with 2 samples per packet are used. ECRTP was used for header compression. - pps can be reduced in the same factor as the number of flows. Up to 40 flows can be grouped together. - in this case, the additional latency would be 20ms (inter-packet = time). This was translated into a 1% reduction of R-Factor (ranging from 1 to = 100). - ITU=92s R-factor [1] is calculated from delay and packet loss - If background traffic appears, optimized traffic can even increase subjective quality, since the overall traffic gets reduced and so does packet loss rate. So optimization increases delay but may reduce packet loss. =20 Another paper about multiplexing VoIP is [3] =20 =20 b) UDP-based online games - The bandwidth savings for 8 games were obtained. For IPv4, 30 or 35% = of the bandwidth was saved. For IPv6 the reduction was between 50 and 55%. - pps were reduced by a factor of 5 or 10 - the additional latency tested was between 5 and 50 ms. The jitter has = to be taken into account, since multiplexing adds jitter (the first packets = are delayed more than the last ones) - A subjective quality estimator for =93Quake IV=94 was used [2]. It is = based on delay and jitter. Packet loss does not matter, because these games = implement very good methods for concealing it. - The MOS could be above 3.5 when multiplexing was on. =20 Jose =20 [1] ITU-T Recommendation G.107 (2011) The E-model, a computational model = for use in transmission planning. =20 [2] Wattimena A.F, Kooij R.E, van Vugt J.M, Ahmed O.K (2006) Predicting = the perceived quality of a first person shooter: the Quake IV G-model. In Proceedings 5th SIGCOMM workshop on Network and system support for games (NetGames '06), ACM, New York, NY, USA =20 [3] Pereira R.M, Tarouco L.M (2009) Adaptive Multiplexing Based on = E-model for Reducing Network Overhead in Voice over IP Security Ensuring Conversation Quality. In Proceedings Fourth international Conference on Digital Telecommunications, Washington DC, pp. 53-58 =20 De: Juli=E1n Fern=E1ndez-Navajas [mailto:navajas@unizar.es]=20 Enviado el: martes, 10 de junio de 2014 13:02 Para: Eggert, Lars; Jose Saldana CC: tcmtf@ietf.org; Martin Stiemerling; tsv-area@ietf.org; = tsvwg@ietf.org Asunto: Re: [tsvwg] New version (v7) of TCM-TF draft =20 Hello Lars, I send you some publications that quantify the benefits (in terms of bandwidth) and drawbacks (in terms of latency and loss). VoIP: this paper evaluates the bandwidth savings and also the influence = of multiplexing on VoIP subjective quality (using ITU=92s E-Model): " Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP Conversation Quality," Computer = Networks (Elsevier), = Volume 56, Issue 7, Pages 1893-1919, May 2012. doi 10.1016/j.comnet.2012.02.004 =20 Online games: This paper also calculates bandwidth savings: =20 First Person Shooters: = Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, vol. 49, no.11, pp. 190-198, November 2011. = doi: 10.1109/MCOM.2011.6069728 =20 And this one is focused on the effect on subjective quality (using a subjective quality estimator for a FPS game): =20 "Online FPS Games: Effect = of Router Buffer and Multiplexing Techniques on Subjective Quality = Estimators," Multimedia Tools and Applications, Springer. doi = 10.1007/s11042-012-1309-4 =20 Regards Juli=E1n =20 El 10/06/2014 10:59, Eggert, Lars escribi=F3: Hi, =20 are there any measurements or simulations that would quantify the = benefits (in terms of bandwidth) and drawbacks (in terms of latency)? =20 Lars =20 _____ =20 ------=_NextPart_000_017B_01CF84C8.592471C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks, = Juli=E1n.

 

Just a brief summary:

 

a) VoIP

- The = bandwidth savings for VoIP could be up to 57%, if RTP and G729a with 2 = samples per packet are used. ECRTP was used for header = compression.

- pps = can be reduced in the same factor as the number of flows. Up to 40 flows = can be grouped together.

- in = this case, the additional latency would be 20ms (inter-packet time). = This was translated into a 1% reduction of R-Factor (ranging from 1 to = 100).

- = ITU’s R-factor [1] is calculated from delay and packet = loss

- If = background traffic appears, optimized traffic can even increase = subjective quality, since the overall traffic gets reduced and so does = packet loss rate. So optimization increases delay but may reduce packet = loss.

 

Another = paper about multiplexing VoIP is [3]

 

 

b) = UDP-based online games

- The = bandwidth savings for 8 games were obtained. For IPv4, 30 or 35% of the = bandwidth was saved. For IPv6 the reduction was between 50 and = 55%.

- pps = were reduced by a factor of 5 or 10

- the = additional latency tested was between 5 and 50 ms. The jitter has to be taken into account, since = multiplexing adds jitter (the first packets are delayed more than the = last ones)

- A = subjective quality estimator for “Quake IV” was used [2]. It = is based on delay and jitter. Packet loss does not matter, because these = games implement very good methods for concealing = it.

- The = MOS could be above 3.5 when multiplexing was on.

 

Jose<= /o:p>

 = ;

[1] ITU-T = Recommendation G.107 (2011) The E-model, a computational model for use = in transmission planning.

 = ;

[2] = Wattimena A.F, Kooij R.E, van Vugt J.M, Ahmed O.K (2006) Predicting the = perceived quality of a first person shooter: the Quake IV G-model. In = Proceedings 5th SIGCOMM workshop on Network and system support for games = (NetGames '06), ACM, New York, NY, USA

 = ;

[3] = Pereira R.M, Tarouco L.M (2009) Adaptive Multiplexing Based on E-model = for Reducing Network Overhead in Voice over IP Security Ensuring = Conversation Quality. In Proceedings Fourth international Conference on = Digital Telecommunications, Washington DC, pp. = 53-58

 

De: = Juli=E1n Fern=E1ndez-Navajas = [mailto:navajas@unizar.es]
Enviado el: martes, 10 de junio de 2014 = 13:02
Para: Eggert, Lars; Jose Saldana
CC: = tcmtf@ietf.org; Martin Stiemerling; tsv-area@ietf.org; = tsvwg@ietf.org
Asunto: Re: [tsvwg] New version (v7) of TCM-TF = draft

 

Hello Lars,

I = send you some publications that quantify the benefits (in terms of = bandwidth) and drawbacks (in terms of latency and = loss).

VoIP: this paper evaluates the bandwidth = savings and also the influence of multiplexing on VoIP subjective = quality (using ITU’s E-Model):

"Evaluating the Influence of Multiplexing Schemes and Buffer = Implementation on Perceived VoIP Conversation = Quality," Computer = Networks (Elsevier), = Volume 56, Issue 7, Pages 1893-1919, May 2012. doi 10.1016/j.comnet.2012.02.004

 =

Online games: = This paper also calculates bandwidth = savings:

First Person Shooters: Can a Smarter = Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, vol. 49, no.11, pp. 190-198, November 2011. doi: 10.1109/MCOM.2011.6069728

 

And this one is = focused on the effect on subjective quality (using a subjective quality = estimator for a FPS game):

"Online FPS Games: Effect of Router = Buffer and Multiplexing Techniques on Subjective Quality = Estimators," Multimedia Tools and Applications, = Springer. doi = 10.1007/s11042-012-1309-4

 

Regards

Juli=E1n

 <= /o:p>

 El 10/06/2014 = 10:59, Eggert, Lars escribi=F3:

Hi,
<= pre> 
are there any measurements or =
simulations that would quantify the benefits (in terms of bandwidth) and =
drawbacks (in terms of =
latency)?
 
Lars

 

------=_NextPart_000_017B_01CF84C8.592471C0-- From nobody Tue Jun 10 10:44: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 7EEEF1A0234 for ; Tue, 10 Jun 2014 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 lxrPlKHhYacp for ; Tue, 10 Jun 2014 10:44:09 -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 B6B6F1A0180 for ; Tue, 10 Jun 2014 10:44:09 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 5C0182B44C5; Tue, 10 Jun 2014 18:44:08 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id B93E72B40E9; Tue, 10 Jun 2014 18:44:07 +0100 (BST) Message-ID: <539743E7.5050300@erg.abdn.ac.uk> Date: Tue, 10 Jun 2014 18:44:07 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg@ietf.org References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <53851C9E.8060002@isi.edu> <53904ED7.1080400@cisco.com> In-Reply-To: <53904ED7.1080400@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mSWl28nlKtuEG4Lczcj4YF5BQOY Cc: Joe Touch Subject: [tsvwg] Conclusion for WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:44:11 -0000 This email follows conclusion of the first WGLC for draft "Recommendations for Transport Port Uses" as draft-ietf-tsvwg-port-use-04.txt. As the chair responsible for this draft, I was pleased to see much discussion on the scope and details of this draft. But, I did not see consensus that this draft is yet ready for publication. I also note one question about the need to publish on this topic. I now request Joe to review the comments and work on updated text to address the issues raised. This will require an updated draft, and discussion within the WG to resolve all important issues, contributions are encouraged to complete this work. If this proceeds, a further WGLC will be needed prior to requesting publication of the draft. Gorry (TSVWG Co-Chair) From nobody Wed Jun 11 00:57: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 A61181A0492 for ; Wed, 11 Jun 2014 00:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 qHub6Jh0BMmQ for ; Wed, 11 Jun 2014 00:57:17 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598D21A0451 for ; Wed, 11 Jun 2014 00:57:16 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jun 2014 09:57:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Wed, 11 Jun 2014 09:57:14 +0200 From: To: , , Date: Wed, 11 Jun 2014 09:57:11 +0200 Thread-Topic: Question about priorities in draft-ietf-tsvwg-rtcweb-qos Thread-Index: Ac+As7Se95OXWwjgSRC0dxpfWr00tAEk5bSg Message-ID: References: <53904CDA.5020902@erg.abdn.ac.uk> In-Reply-To: <53904CDA.5020902@erg.abdn.ac.uk> 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/R-SXAa7vK8VJOl0N-V8BN-ltA-A Cc: tsvwg@ietf.org Subject: [tsvwg] Question about priorities in draft-ietf-tsvwg-rtcweb-qos 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, 11 Jun 2014 07:57:19 -0000 Dear chairs, draft-ietf-tsvwg-rtcweb-qos - does not change existing IETF DiffServ specs - introduces a priority and defines it as: The following are the inputs that the browser provides to the media engi= ne: o Data Type: The browser provides this input as it knows if the flow is audio, interactive video with or without audio, non-interactive video with or without audio, or data. o Priority: Another input is the relative treatment of the flow within that data type. Many applications have multiple media flows of the same data type and often some are more important than others. Likewise, in a video conference where the flows in the conference is of the same data type but contains different media types, the flow for audio may be more important than the video flow. JavaScript applications can tell the browser whether a particular media flow is high, medium, low or very low importance to the application. When it comes to data transmission, a media (data) flow is the SCTP stream under a common congestion control (currently within the same SCTP association). And then assigns priorities in table 1: Table 1 The columns "very low", "low", "Medium" and "high" are the priority l= evels. I'd appreciate a clarification on how that corresponds with the DiffServ ar= chitecture,=20 RFC2575: This architecture is composed of a number of functional elements implemented in network nodes, including a small set of per-hop forwarding behaviors, .... This architecture achieves scalability by imp= lementing complex classification and conditioning functions only at network boundary nodes, and by applying per-hop behaviors to aggregates of traffic which have been appropriately marked using the DS field in the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to permit a reasonably granular means of allocating buffer and bandwidth resources at each node among competing traffic streams. Per- application flow or per-customer forwarding state need not be maintained within the core of the network. Please clarify whether a browser is network boundary node in the sense of R= FC2575.=20 And whether DiffServ has been designed to "tell the browser whether a parti= cular media=20 flow is high, medium, low or very low importance to the application." While looking into the DiffServ WG archive, I also found http://tools.ietf.= org/html/rfc3140 . The approach taken there may be helpful in exchanging "intended PHB" inform= ation in=20 environments, where codepoints may change. Just as an info, no request to b= e applied. This mail doesn't state right or wrong - I'd just like to understand what=20 DiffServ is about and especially, what an "aggregation of traffic" means. F= rom=20 discussion about draft-york-dart-dscp-rtp-00, I've learned, that a fair num= ber=20 of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow and this starts= =20 to put my interpretation of DiffServ somewhat off track. Regards, Ruediger From nobody Wed Jun 11 07:56:59 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 6539D1A015C for ; Wed, 11 Jun 2014 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZJcL1jfCzBn for ; Wed, 11 Jun 2014 07:56:51 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 2C0F21A0141 for ; Wed, 11 Jun 2014 07:56:51 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1WujxI-0000SZ-CN; Wed, 11 Jun 2014 16:56:48 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 66F57A80126; Wed, 11 Jun 2014 16:56:49 +0200 (CEST) Message-ID: <53986E30.6080207@kit.edu> Date: Wed, 11 Jun 2014 16:56:48 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <53904CDA.5020902@erg.abdn.ac.uk> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1402498608. Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/lk6yz9vwd4MyzturQTLCxTDdDs4 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Question about priorities in draft-ietf-tsvwg-rtcweb-qos 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, 11 Jun 2014 14:56:57 -0000 Hi Ruediger and all, Am 11.06.2014 09:57, schrieb Ruediger.Geib@telekom.de: > I'd appreciate a clarification on how that corresponds with the DiffServ architecture, > RFC2575: > > This architecture is composed of a number of functional elements > implemented in network nodes, including a small set of per-hop > forwarding behaviors, .... This architecture achieves scalability by implementing > complex classification and conditioning functions only at network > boundary nodes, and by applying per-hop behaviors to aggregates of > traffic which have been appropriately marked using the DS field in > the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to > permit a reasonably granular means of allocating buffer and bandwidth > resources at each node among competing traffic streams. Per- > application flow or per-customer forwarding state need not be > maintained within the core of the network. > > Please clarify whether a browser is network boundary node in the sense of RFC2575. You mean the DS boundary node mentioned in RFC2475 I guess. My interpretation is: if the end-system on which the browser resides is "trusted" then it can be considered as being a DS boundary node, because it sets the initial marking. However, the draft explicitly says: % The DSCP value set by the endpoint is not always trusted by the % network. Therefore, the DSCP value may be remarked at the network % edge through policy to any other DSCP value, including best effort. This is clear enough IMHO. The main weakness of DiffServ is that once the flow has entered the DS region, you have to deal with it - there is normally no way to punish/push back single "misbehaving flows". > And whether DiffServ has been designed to "tell the browser whether a particular media > flow is high, medium, low or very low importance to the application." No, DiffServ was designed to be application-independent and only distinguishes between different behavior aggregates. By using the mapping table this is indirectly reflected by using different DSCPs/PHBs. I don't see any problem here. > While looking into the DiffServ WG archive, I also found http://tools.ietf.org/html/rfc3140 . > The approach taken there may be helpful in exchanging "intended PHB" information in > environments, where codepoints may change. Just as an info, no request to be applied. Correct, and indeed it would be better to signal PHB-IDs, but this cannot be done within the packets, one would need an extra signaling protocol for this. > This mail doesn't state right or wrong - I'd just like to understand what > DiffServ is about and especially, what an "aggregation of traffic" means. From > discussion about draft-york-dart-dscp-rtp-00, I've learned, that a fair number > of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow and this starts > to put my interpretation of DiffServ somewhat off track. The DS architecture does not preclude using a multi-field classifier that goes beyond the 5 tuple classifier (identifying a micro-flow in DS terminology). It's actually more work for the classifier within the DS boundary node. The DS architecture doesn't forbid to have a micro-flow with different DSCP markings in it, but it is mentioned several times that packet reordering within a micro-flow due to that different marking should be avoided. I have more comments w.r.t. the draft and will write another e-mail for that. Regards, Roland -- PD Dr. Roland Bless -- WWW: http://tm.kit.edu/~bless Institut für Telematik, Karlsruher Institut für Technologie (KIT) Postf. 6980, 76049 Karlsruhe -- Zirkel 2, Geb. 20.20, 3.OG, Raum 358 Tel.: +49-721-608-46413 Mob.: +49-152-0160-1400 Fax: +49-721-608-46789 From nobody Wed Jun 11 12:42:35 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 A9CCE1B289B for ; Wed, 11 Jun 2014 12:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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.651, 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 nUfOAuQdlsOi for ; Wed, 11 Jun 2014 12:42:26 -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 74F8A1A0202 for ; Wed, 11 Jun 2014 12:42:26 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5BJgNZF010526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 15:42:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5BJgNZF010526 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402515745; bh=VObfgkpAlCO+EqCGBAgmqf56QMI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=U9eD+7EaHobF8zQVuZlRIgIvgTjozyQX81pMPBVUcF7pOXXpy9R5jM/+myU0/XVGg juhg84cOuxXhut9cZ/pqTjRCuWJE9TeMAkoi/73xvy9RRH0JS7uLtBk4ZhDnnQNfxk HC+3C4udDXFZP+CgUt+Q93x/9/RWXBYocRKh90hA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s5BJgNZF010526 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd04.lss.emc.com (RSA Interceptor); Wed, 11 Jun 2014 12:42:11 -0700 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5BJgAmW016106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 15:42:11 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 11 Jun 2014 15:42:10 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Wed, 11 Jun 2014 15:42:08 -0400 Thread-Topic: Question about priorities in draft-ietf-tsvwg-rtcweb-qos Thread-Index: Ac+As7Se95OXWwjgSRC0dxpfWr00tAEk5bSgABiVg3A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD348B0@MX15A.corp.emc.com> References: <53904CDA.5020902@erg.abdn.ac.uk> 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: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/FtmzP7VjSSeuBnWgJNDb86iuolU Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Question about priorities in draft-ietf-tsvwg-rtcweb-qos 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, 11 Jun 2014 19:42:30 -0000 I'll respond anyway as one of the original designers of DiffServ. draft-ietf-tsvwg-rtcweb-qos is about mapping from an application API to network functionality. The media engine is not part of the application - it's part of the browser or other application framework. That draft is concerned with how the browser or other framework determines the initial DSCP marking to apply to packets that it sends (well, asks the system that hosts it and the application to send). Attempting to respond to the requests: > Please clarify whether a browser is network boundary node in the > sense of RFC2575. That would be RFC 2475 ;-). A browser is definitely not a network boundary node (FWIW, I'm one of the authors of RFC 2475) - the first network boundary node that a packet encounters will usually be after a DSCP-marked packet is sent by (and leaves) the system on which the browser is running.=20 > And whether DiffServ has been designed to "tell the browser whether a > particular media flow is high, medium, low or very low importance to > the application." No, it was not; a browser is not a network node. That statement in that draft is about the API between an application and browser or other framework, which is outside of any DiffServ domain. > While looking into the DiffServ WG archive, I also found > http://tools.ietf.org/html/rfc3140 . > The approach taken there may be helpful in exchanging "intended PHB" > information in environments, where codepoints may change. Just as an > info, no request to be applied. I actually prefer the approach in draft-ietf-tsvwg-rtcweb-qos, as it insulates PHB selection and details from application programmers, presenting them with a simpler, more abstract model. > This mail doesn't state right or wrong - I'd just like to understand what > DiffServ is about and especially, what an "aggregation of traffic" means. > From discussion about draft-york-dart-dscp-rtp-00, I've learned, that a > fair number of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow > and this starts to put my interpretation of DiffServ somewhat off track. That mixing of PHBs on a single UDP 5-tuple is actually a new concept - draft-york-dart-dscp-rtp-00 picked that concept up from draft-ietf-rtcweb-transports-05, which contains details on what RTCWEB intends to do in this area. That concept should be open to discussion on the dart list, as this mixing of PHBs on a single 5-tuple (aside from mixing the PHBs that constitute a single AF class) was not anticipated in the original DiffServ architecture/design. Thanks, --David (co-author of RFC 2475, RFC 3140 and draft-york ... but that doesn't mean that I know all the answers ...). > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, June 11, 2014 3:57 AM > To: gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > Cc: tsvwg@ietf.org > Subject: Question about priorities in draft-ietf-tsvwg-rtcweb-qos >=20 > Dear chairs, >=20 > draft-ietf-tsvwg-rtcweb-qos >=20 > - does not change existing IETF DiffServ specs > - introduces a priority and defines it as: >=20 > The following are the inputs that the browser provides to the media en= gine: >=20 > o Data Type: The browser provides this input as it knows if the fl= ow > is audio, interactive video with or without audio, non-interacti= ve > video with or without audio, or data. > o Priority: Another input is the relative treatment of the flow > within that data type. Many applications have multiple media > flows of the same data type and often some are more important th= an > others. Likewise, in a video conference where the flows in the > conference is of the same data type but contains different media > types, the flow for audio may be more important than the video > flow. JavaScript applications can tell the browser whether a > particular media flow is high, medium, low or very low importanc= e > to the application. >=20 > When it comes to data transmission, a media (data) flow is the SCTP > stream under a common congestion control (currently within the same > SCTP association). >=20 > And then assigns priorities in table 1: >=20 > Table 1 >=20 > The columns "very low", "low", "Medium" and "high" are the priority > levels. >=20 > I'd appreciate a clarification on how that corresponds with the DiffServ > architecture, > RFC2575: >=20 > This architecture is composed of a number of functional elements > implemented in network nodes, including a small set of per-hop > forwarding behaviors, .... This architecture achieves scalability by > implementing > complex classification and conditioning functions only at network > boundary nodes, and by applying per-hop behaviors to aggregates of > traffic which have been appropriately marked using the DS field in > the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to > permit a reasonably granular means of allocating buffer and bandwidth > resources at each node among competing traffic streams. Per- > application flow or per-customer forwarding state need not be > maintained within the core of the network. >=20 > Please clarify whether a browser is network boundary node in the sense of > RFC2575. > And whether DiffServ has been designed to "tell the browser whether a > particular media > flow is high, medium, low or very low importance to the application." >=20 > While looking into the DiffServ WG archive, I also found > http://tools.ietf.org/html/rfc3140 . > The approach taken there may be helpful in exchanging "intended PHB" > information in > environments, where codepoints may change. Just as an info, no request to= be > applied. >=20 > This mail doesn't state right or wrong - I'd just like to understand what > DiffServ is about and especially, what an "aggregation of traffic" means.= From > discussion about draft-york-dart-dscp-rtp-00, I've learned, that a fair n= umber > of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow and this star= ts > to put my interpretation of DiffServ somewhat off track. >=20 > Regards, >=20 > Ruediger From nobody Wed Jun 11 13:35: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 832CB1A0298 for ; Wed, 11 Jun 2014 13:35:05 -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 GBAjmptDx-K8 for ; Wed, 11 Jun 2014 13:35:03 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394501A027F for ; Wed, 11 Jun 2014 13:35:03 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id bj1so192486pad.7 for ; Wed, 11 Jun 2014 13:35:02 -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=TZ0OJWEfKgCjy3tk/x5BEF8WT3CXCVrUQIt03KjpknQ=; b=aUKt2Z82nwgAsbnXL5LuszsWjVIS9xfksMo3sP/Fgx8mQzLpPATdynfJuGzTC+gX1l s/LVJeLOa8zyhdEEZz5I4tBW5M5l8G+FfiAJjaoW7mvE10Uh6PxaO5Xz4va9aKR8kpB0 Wu/7QXFbd8FSjxFasK9/EvLXm/PQuOh0tFqMV9dA+68xBgHAIVunHdd1i9xgpWpLkcPZ CIoGDBjBubBa/xEiw6Q765BSCdRIdpm9dm5F75jZFi08Mh7hygACINOdKNPUfaoujtwi iet9GJeHUzK0pYvpUMuGcsf1S+aEm+daPQrN+re+IMzI2Xi+38R/V/BeU0jXWpxHa4Jn 8msg== X-Received: by 10.66.137.109 with SMTP id qh13mr16267701pab.39.1402518902876; Wed, 11 Jun 2014 13:35:02 -0700 (PDT) Received: from [192.168.178.23] (68.195.69.111.dynamic.snap.net.nz. [111.69.195.68]) by mx.google.com with ESMTPSA id sh5sm76597709pbc.21.2014.06.11.13.35.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 13:35:02 -0700 (PDT) Message-ID: <5398BD7A.7010500@gmail.com> Date: Thu, 12 Jun 2014 08:35:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Black, David" References: <53904CDA.5020902@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076FD348B0@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD348B0@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/4uJcomvPW82i7Km2K2ngN56fdkM Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Question about priorities in draft-ietf-tsvwg-rtcweb-qos 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, 11 Jun 2014 20:35:05 -0000 On 12/06/2014 07:42, Black, David wrote: > > > I'll respond anyway as one of the original designers of DiffServ. > > draft-ietf-tsvwg-rtcweb-qos is about mapping from an application > API to network functionality. The media engine is not part of the > application - it's part of the browser or other application framework. > That draft is concerned with how the browser or other framework > determines the initial DSCP marking to apply to packets that it > sends (well, asks the system that hosts it and the application to > send). > > Attempting to respond to the requests: > >> Please clarify whether a browser is network boundary node in the >> sense of RFC2575. > > That would be RFC 2475 ;-). > > A browser is definitely not a network boundary node (FWIW, I'm one > of the authors of RFC 2475) - the first network boundary node that > a packet encounters will usually be after a DSCP-marked packet > is sent by (and leaves) the system on which the browser is running. > >> And whether DiffServ has been designed to "tell the browser whether a >> particular media flow is high, medium, low or very low importance to >> the application." > > No, it was not; a browser is not a network node. That statement in > that draft is about the API between an application and browser or > other framework, which is outside of any DiffServ domain. Yes, which is just as well, since diffsev doesn't deal in priorities (the nearest it gets is the backwards-compatible precedence classes). An application can legitimately have priorities between its own packets, because it understands which ones are more important. But diffserv is blind to application semantics; all it really does is provide a way of selecting different queueing disciplines for different traffic streams. Quite how we match those two worlds together has always been an interesting question, which I assume will be debated in DART. Brian > >> While looking into the DiffServ WG archive, I also found >> http://tools.ietf.org/html/rfc3140 . >> The approach taken there may be helpful in exchanging "intended PHB" >> information in environments, where codepoints may change. Just as an >> info, no request to be applied. > > I actually prefer the approach in draft-ietf-tsvwg-rtcweb-qos, as it > insulates PHB selection and details from application programmers, > presenting them with a simpler, more abstract model. > >> This mail doesn't state right or wrong - I'd just like to understand what >> DiffServ is about and especially, what an "aggregation of traffic" means. >> From discussion about draft-york-dart-dscp-rtp-00, I've learned, that a >> fair number of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow >> and this starts to put my interpretation of DiffServ somewhat off track. > > That mixing of PHBs on a single UDP 5-tuple is actually a new concept - > draft-york-dart-dscp-rtp-00 picked that concept up from > draft-ietf-rtcweb-transports-05, which contains details on what RTCWEB > intends to do in this area. That concept should be open to discussion on > the dart list, as this mixing of PHBs on a single 5-tuple (aside from > mixing the PHBs that constitute a single AF class) was not anticipated > in the original DiffServ architecture/design. > > Thanks, > --David (co-author of RFC 2475, RFC 3140 and draft-york ... but that > doesn't mean that I know all the answers ...). > > > >> -----Original Message----- >> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >> Sent: Wednesday, June 11, 2014 3:57 AM >> To: gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com >> Cc: tsvwg@ietf.org >> Subject: Question about priorities in draft-ietf-tsvwg-rtcweb-qos >> >> Dear chairs, >> >> draft-ietf-tsvwg-rtcweb-qos >> >> - does not change existing IETF DiffServ specs >> - introduces a priority and defines it as: >> >> The following are the inputs that the browser provides to the media engine: >> >> o Data Type: The browser provides this input as it knows if the flow >> is audio, interactive video with or without audio, non-interactive >> video with or without audio, or data. >> o Priority: Another input is the relative treatment of the flow >> within that data type. Many applications have multiple media >> flows of the same data type and often some are more important than >> others. Likewise, in a video conference where the flows in the >> conference is of the same data type but contains different media >> types, the flow for audio may be more important than the video >> flow. JavaScript applications can tell the browser whether a >> particular media flow is high, medium, low or very low importance >> to the application. >> >> When it comes to data transmission, a media (data) flow is the SCTP >> stream under a common congestion control (currently within the same >> SCTP association). >> >> And then assigns priorities in table 1: >> >> Table 1 >> >> The columns "very low", "low", "Medium" and "high" are the priority >> levels. >> >> I'd appreciate a clarification on how that corresponds with the DiffServ >> architecture, >> RFC2575: >> >> This architecture is composed of a number of functional elements >> implemented in network nodes, including a small set of per-hop >> forwarding behaviors, .... This architecture achieves scalability by >> implementing >> complex classification and conditioning functions only at network >> boundary nodes, and by applying per-hop behaviors to aggregates of >> traffic which have been appropriately marked using the DS field in >> the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to >> permit a reasonably granular means of allocating buffer and bandwidth >> resources at each node among competing traffic streams. Per- >> application flow or per-customer forwarding state need not be >> maintained within the core of the network. >> >> Please clarify whether a browser is network boundary node in the sense of >> RFC2575. >> And whether DiffServ has been designed to "tell the browser whether a >> particular media >> flow is high, medium, low or very low importance to the application." >> >> While looking into the DiffServ WG archive, I also found >> http://tools.ietf.org/html/rfc3140 . >> The approach taken there may be helpful in exchanging "intended PHB" >> information in >> environments, where codepoints may change. Just as an info, no request to be >> applied. >> >> This mail doesn't state right or wrong - I'd just like to understand what >> DiffServ is about and especially, what an "aggregation of traffic" means. From >> discussion about draft-york-dart-dscp-rtp-00, I've learned, that a fair number >> of tsvwg-rtcweb-qos PHBs may occur in a single 5 tuple flow and this starts >> to put my interpretation of DiffServ somewhat off track. >> >> Regards, >> >> Ruediger > > From nobody Thu Jun 12 06:39: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 719A21B2A1C; Thu, 12 Jun 2014 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqieqdTW9YJ3; Thu, 12 Jun 2014 06:39:14 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 E9A9C1B2A2C; Thu, 12 Jun 2014 06:39:13 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1Wv5Dh-00070y-Jp; Thu, 12 Jun 2014 15:39:09 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id CA6FEA808C0; Thu, 12 Jun 2014 15:39:11 +0200 (CEST) Message-ID: <5399AD7F.20805@kit.edu> Date: Thu, 12 Jun 2014 15:39:11 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1402580349. Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/6YwxhSdUfEvxHPTPK6NcQU_G4PQ Cc: dart@ietf.org Subject: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 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, 12 Jun 2014 13:39:16 -0000 Hi, some remarks on draft-ietf-tsvwg-rtcweb-qos-00: Sec. 2: The mitigation for such action is through an authorization mechanism. An authorization mechanism alone is probably not sufficient, because DS boundary nodes may need to police (e.g., remark/drop) incoming traffic according to some agreed/negotiated traffic profile for some of the PHBs, e.g., the EF PHB does not work properly if its traffic class is overloaded (see below). Sec. 4: The below uses the concept of a media flow, however these are commonly not equivalent to a transport flow, i.e. as defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). I think one should try to use definitions that do not depend on the classifier type like 5-tuple, because as Brian already mentioned, for IPv6 a 3-tuple (IPsrc, IPdst, Flow Label) may be sufficient and header fields of the 5-tuple are not always accessible. I liked the definition of microflow in DiffServ as being an application-to-application flow of packets, usually being identified by that well known 5-tuple. For elements within the network microflows are usually the most fine grained distinction level for flows (except when you apply multi-field classifier that do some DPI and add the SSRC etc.). (nit: is probably a word like "text" missing in the first cited sentence above?) Proper definitions for media flow, RTP session, transport flow etc. may help to avoid confusion, so maybe one could try to combine efforts with draft-york-dart-dscp-rtp-00? Sec. 5: SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. The problem with using EF is that if too many EF marked packets are injected into a DS domain, they probably void the EF properties for other users within this domain (background is that the service rate of EF packets on a given output interface must exceed their arrival rate at that interface over long and short time intervals - this is usually checked by admission control before use and policing at DS boundary nodes during use). Therefore, maybe some discussion w.r.t. RFC5865 http://tools.ietf.org/html/rfc5865 may be useful. The above table assumes that packets marked with CS1 is treated as "less than best effort". However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the priority of the packets may be changed from what is intended. BTW, there is no "less than best effort" PHB defined, but a Lower Effort Per-Domain Behavior (PDB) in RFC 3662 (http://tools.ietf.org /html/rfc3662). This RFC is also the source for the recommendation of using the CS-1 codepoint for that purpose, so you may considering referencing it. If a packet enters a QoS domain that has no support for the above defined Data Types/Application (service) classes, then the network node at the edge will remark the DSCP value based on policies. Yes, but even if there is support for these classes traffic conditioning (e.g., remarking/dropping etc.) may be necessary and applied. Remarking to different PHBs may also lead to packet reordering within a media flow?! Regards, Roland From nobody Fri Jun 13 13:09: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 2CB4C1B27FB for ; Fri, 13 Jun 2014 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 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.651, 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 c7PW7wvMvSKy for ; Fri, 13 Jun 2014 13:09:29 -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 956941A023A for ; Fri, 13 Jun 2014 13:09:29 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5DK9R8S019354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jun 2014 16:09:28 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5DK9R8S019354 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402690168; bh=09RB1FD3OPUJhIRkssdToSzYwiY=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Zk/R51ddJuP/sVTyYAqS/I6EbTaMvq9Qj+m0VSgVbT5rnalaVPC/l9zxRwM6zFyXE hWI7bbxQJpbpufxJi+BFoBlSA7bMHA15rStAt9Px/I4b7Ww24NyMxr5ALGBWcsxuRN AaXYUXpCZoD+bTjmQrjT3pf1tur0A4kax+bBd0NU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s5DK9R8S019354 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Fri, 13 Jun 2014 16:09:09 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5DK98dh018779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Jun 2014 16:09:09 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Fri, 13 Jun 2014 16:09:08 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Fri, 13 Jun 2014 16:09:03 -0400 Thread-Topic: third call: NomCom 2014-2015 Call for Volunteers Thread-Index: Ac+HNS3J15FsbRTzQRWvXcHouNmcvwADhSqg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF26888@MX15A.corp.emc.com> References: <20140613161232.7221.35693.idtracker@ietfa.amsl.com> In-Reply-To: <20140613161232.7221.35693.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9-b3AAMudTO5YSsK2vk6igUWiXc Subject: [tsvwg] FW: third call: NomCom 2014-2015 Call for Volunteers 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, 13 Jun 2014 20:09:32 -0000 UGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZyB0byBzZXJ2ZXIgb24gdGhlIE5vbUNvbS4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYtQW5ub3VuY2UgW21haWx0bzpp ZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOb21Db20gQ2hhaXIg MjAxNA0KU2VudDogRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDEyOjEzIFBNDQpUbzogSUVURiBBbm5v dW5jZW1lbnQgTGlzdA0KU3ViamVjdDogdGhpcmQgY2FsbDogTm9tQ29tIDIwMTQtMjAxNSBDYWxs IGZvciBWb2x1bnRlZXJzDQoNClRoaXMgaXMgdGhlIHRoaXJkIGNhbGwgZm9yIHZvbHVudGVlcnMu DQpWT0xVTlRFRVIgTk9XOiB3ZSBuZWVkIHRvIG1ha2UgMjAwLg0KVGhlIERFQURMSU5FIGlzIEp1 bmUgMjYgdG8gdm9sdW50ZWVyLg0KDQpUaGUgSUVURiBub21jb20gYXBwb2ludHMgZm9sa3MgdG8g ZmlsbCB0aGUgb3BlbiBzbG90cyBvbiB0aGUgSUFPQywgdGhlIElBQiwNCmFuZCB0aGUgSUVTRyAo aW5jbHVkaW5nIElFVEYgQ2hhaXIpLg0KDQpJZiB5b3VyIG5hbWUgaXMgb24gdGhlIGJlbG93LCB0 aGVuIHlvdSBoYXZlIHZvbHVudGVlcmVkIGFuZCBhcmUgcXVhbGlmaWVkLg0KSW4gYWRkaXRpb24g dG8gdGhvc2Ugd2hvIHZvbHVudGVlcmVkIGJ5IGVtYWlsLCBpdCBhbHNvIGluY2x1ZGVzIHRob3Nl IHdobw0KaW5kaWNhdGVkIHRoZWlyIHdpbGxpbmduZXNzIHRvIHNlcnZlIG9uIHRoZSBJRVRGOTAg cmVnaXN0cmF0aW9uIGZvcm0sIGFuZA0Kd2hvc2UgZWxpZ2liaWxpdHkgaGFzIGJlZW4gY29uZmly bWVkLiAgNTQgcGVvcGxlIHdlcmUgY29uZmlybWVkIHRvIGJlDQplbGlnaWJsZSwgYW5kIDcwIHBl b3BsZSB3ZXJlIG5vdCBjb25maXJtZWQgYmFzZWQgdXBvbiB0aGUgZW1haWwgdGhleSBoYXZlDQp1 c2VkIHRvIHJlZ2lzdGVyLiAgIFRob3NlIDEyNCBwZW9wbGUgaGF2ZSBiZWVuIGNvbnRhY3RlZCBk aXJlY3RseS4NCg0KSWYgeW91IGhhdmUgaGVhcmQgZnJvbSBtZSwgYnV0IGFyZSBub3Qgb24gdGhl IGxpc3QsIHRoZW4gdGhlcmUgaXMgc29tZQ0KcHJvYmxlbSwgYW5kIHlvdSBzaG91bGQgaGF2ZSBn b3R0ZW4gYSBxdWVyeSBmcm9tIG1lIHRvIGRldGVybWluZSB5b3VyDQplbGlnaWJpbGl0eS4NCg0K SWYgeW91IGhhdmUgdm9sdW50ZWVyZWQgYW5kIG5vdCBoZWFyZCBmcm9tIGhpbSwgdGhlbiBwbGVh c2UgcmVzZW5kOw0KaXQgZ290IGxvc3QuDQoNClRlbiB2b3RpbmcgbWVtYmVycyBmb3IgdGhlIG5v bWNvbSBhcmUgc2VsZWN0ZWQgaW4gYSB2ZXJpZmlhYmx5IHJhbmRvbQ0Kd2F5IGZyb20gYSBwb29s IG9mIHZvbHVudGVlcnMuIFRoZSBtb3JlIHZvbHVudGVlcnMsIHRoZSBiZXR0ZXIgY2hhbmNlIHdl IGhhdmUNCm9mIGNob29zaW5nIGEgcmFuZG9tIHlldCByZXByZXNlbnRhdGl2ZSBjcm9zcyBzZWN0 aW9uIG9mIHRoZSBJRVRGIHBvcHVsYXRpb24uDQoNCkxldCdzIGJyZWFrIHRoZSAyMDAgdm9sdW50 ZWVyIG1hcmsgYWdhaW4gdGhpcyB5ZWFyIQ0KV2UgYXJlIGF0IDEyMyB2b2x1bnRlZXJzIHNvIGZh ciwgYW5kIFdFIE5FRUQgVE8gSEFWRSAyMDAhISENCg0KVGhlIGRldGFpbHMgb2YgdGhlIG9wZXJh dGlvbiBvZiB0aGUgbm9tY29tIGNhbiBiZSBmb3VuZCBpbiBSRkMgMzc3NywNCmFuZCBCQ1AxMC9S RkMzNzk3IGRldGFpbHMgdGhlIHNlbGVjdGlvbiBhbGdvcml0aG0uDQoNClZvbHVudGVlcnMgbXVz dCBoYXZlIGF0dGVuZGVkIDMgb2YgdGhlIHBhc3QgNSBJRVRGIG1lZXRpbmdzLiAgQXMgc3BlY2lm aWVkIGluDQpSRkMgMzc3NywgdGhhdCBtZWFucyB0aHJlZSBvdXQgb2YgdGhlIGZpdmUgcGFzdCBt ZWV0aW5ncyB1cCB0byB0aGUgdGltZSB0aGlzDQplbWFpbCBhbm5vdW5jZW1lbnQgZ29lcyBvdXQg dG8gc3RhcnQgdGhlIHNvbGljaXRhdGlvbiBvZiB2b2x1bnRlZXJzLg0KVGhlIGZpdmUgbWVldGlu Z3Mgb3V0IG9mIHdoaWNoIHlvdSBtdXN0IGhhdmUgYXR0ZW5kZWQgKnRocmVlKg0KYXJlIElFVEYg ODUoQXRsYW50YSksICAgICAgXA0KICAgICAgICAgODYoT3JsYW5kbyksICAgICAgIFwNCiAgICAg ICAgIDg3KEJlcmxpbiksICAgICAgICAgKioqIEFOWSBUSFJFRSENCiAgICAgICAgIDg4KFZhbmNv dXZlciksICAgICAvDQogICAgICAgICA4OShMb25kb24pICAgICAgICAvDQoNCklmIHlvdSBxdWFs aWZ5LCBwbGVhc2Ugdm9sdW50ZWVyLiAgIEhvd2V2ZXIsIG11Y2ggYXMgd2Ugd2FudCB0aGlzLCBi ZWZvcmUgeW91DQpkZWNpZGUgdG8gdm9sdW50ZWVyLCBwbGVhc2UgYmUgc3VyZSB5b3UgYXJlIHdp bGxpbmcgdG8gZm9yZ28gYXBwb2ludG1lbnQNCnRvIGFueSBvZiB0aGUgcG9zaXRpb25zIGZvciB3 aGljaCB0aGlzIG5vbWNvbSBpcyByZXNwb25zaWJsZS4NCg0KVGhlIGxpc3Qgb2YgcGVvcGxlIGFu ZCBwb3N0cyB3aG9zZSB0ZXJtcyBlbmQgd2l0aCB0aGUgTWFyY2ggMjAxNSBJRVRGDQptZWV0aW5n LCBhbmQgdGh1cyB0aGUgcG9zaXRpb25zIGZvciB3aGljaCB0aGlzIG5vbWNvbSBpcyByZXNwb25z aWJsZSwgYXJlDQoNCklBT0M6DQpUbyBiZSBjb25maXJtZWQNCg0KSUFCOg0KSm9lbCBIYWxwZXJu DQpSdXNzIEhvdXNsZXkNCkVsaW90IExlYXINClhpbmcgTGkNCkFuZHJldyBTdWxsaXZhbg0KRGF2 ZSBUaGFsZXINCg0KSUVTRzoNClBldGUgUmVzbmljayAoQXBwbGljYXRpb25zKQ0KVGVkIExlbW9u IChJbnRlcm5ldCkNCkpvZWwgSmFlZ2dsaSAoT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCkNClJp Y2hhcmQgQmFybmVzIChSQUkpDQpBZHJpYW4gRmFycmVsKiAoUm91dGluZykNClN0ZXBoZW4gRmFy cmVsbCAoU2VjdXJpdHkpDQpTcGVuY2VyIERhd2tpbnMgKFRyYW5zcG9ydCkNCkphcmkgQXJra28g KEdlbikNCg0KKG5hbWVzIHdpdGggKiBoYXZlIHB1YmxpY2FsbHkgaW5kaWNhdGVkIHRoZXkgd2ls bCBub3Qgc2VydmUgYW5vdGhlciB0ZXJtKQ0KDQpUaGUgcHJpbWFyeSBhY3Rpdml0eSBmb3IgdGhp cyBub21jb20gd2lsbCBiZWdpbiBpbiBKdWx5IDIwMTQgYW5kIHNob3VsZCBiZQ0KY29tcGxldGVk IGluIEphbnVhcnkgMjAxNS4gICBUaGUgbm9tY29tIHdpbGwgaGF2ZSByZWd1bGFybHkgc2NoZWR1 bGVkDQpjb25mZXJlbmNlIGNhbGxzIHRvIGVuc3VyZSBwcm9ncmVzcy4gKFdlIG1pZ2h0IGRvZ2Zv b2QgV2ViUlRDKQ0KVGhlcmUgd2lsbCBiZSBhY3Rpdml0aWVzIHRvIGNvbGxlY3QgcmVxdWlyZW1l bnRzIGZyb20gdGhlIGNvbW11bml0eSwgcmV2aWV3DQpjYW5kaWRhdGUgcXVlc3Rpb25uYWlyZXMs IHJldmlldyBmZWVkYmFjayBmcm9tIGNvbW11bml0eSBtZW1iZXJzIGFib3V0DQpjYW5kaWRhdGVz LCBhbmQgdGFsayB0byBjYW5kaWRhdGVzLg0KDQpUaHVzLCBiZWluZyBhIG5vbWNvbSBtZW1iZXIg ZG9lcyByZXF1aXJlIHNvbWUgdGltZSBjb21taXRtZW50OyBidXQgaXQgaXMgYWxzbw0KYSB2ZXJ5 IHJld2FyZGluZyBleHBlcmllbmNlLg0KDQpJdCBpcyB2ZXJ5IGltcG9ydGFudCB0aGF0IHlvdSBi ZSBhYmxlIHRvIGF0dGVuZCBJRVRGOTEgdG8gY29uZHVjdCBpbnRlcnZpZXdzLg0KQmVpbmcgYXQg SUVURjkwIGlzIHVzZWZ1bCBmb3IgdHJhaW5pbmcuICBCZWluZyBhdCBJRVRGOTIgaXMgbm90IGVz c2VudGlhbC4NCg0KUGxlYXNlIHZvbHVudGVlciBieSBzZW5kaW5nIG1lIGFuIGVtYWlsIGJlZm9y ZSAxMTo1OSBwbSBFRFQgKFVUQyAtNCBob3VycykNCkp1bmUgMjIsIDIwMTMsIGFzIGZvbGxvd3M6 DQoNClRvOiBub21jb20tY2hhaXItMjAxNEBpZXRmLm9yZw0KU3ViamVjdDogTm9tY29tIDIwMTQt MTUgVm9sdW50ZWVyDQoNClBsZWFzZSBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24g aW4gdGhlIGVtYWlsIGJvZHk6DQoNCllvdXIgRnVsbCBOYW1lOiBfX19fX19fX19fLS0NCkN1cnJl bnQgUHJpbWFyeSBBZmZpbGlhdGlvbjoNCiAgICAvLyBUeXBpY2FsbHkgd2hhdCBnb2VzIGluIHRo ZSBDb21wYW55IGZpZWxkDQogICAgLy8gaW4gdGhlIElFVEYgUmVnaXN0cmF0aW9uIEZvcm0NCkVt YWlsczogX19fX19fX19fX19fX19fDQpbPEFsbCBlbWFpbCBhZGRyZXNzZXMgdXNlZCB0byByZWdp c3RlciBmb3IgdGhlIHBhc3QgNSBJRVRGIG1lZXRpbmdzPl0NCiA8UHJlZmVycmVkIGVtYWlsIGFk ZHJlc3MgZmlyc3Q+DQpUZWxlcGhvbmU6IF9fX19fX19fX19fX19fX19fX19fX19fDQogICAgLy8g Rm9yIGNvbmZpcm1hdGlvbiBpZiBzZWxlY3RlZA0KDQpZb3Ugc2hvdWxkIGV4cGVjdCBhbiBlbWFp bCByZXNwb25zZSBmcm9tIG1lIHdpdGhpbiAzIGJ1c2luZXNzIGRheXMgc3RhdGluZw0Kd2hldGhl ciBvciBub3QgeW91IGFyZSBxdWFsaWZpZWQuICBJZiB5b3UgZG9uJ3QgcmVjZWl2ZSB0aGlzIHJl c3BvbnNlLA0KcGxlYXNlIHJlLXNlbmQgeW91ciBlbWFpbCB3aXRoIHRoZSB0YWcgIlJFU0VORCIi IGFkZGVkIHRvIHRoZSBzdWJqZWN0IGxpbmUuDQoNCklmIHlvdSBhcmUgbm90IHlldCBzdXJlIGlm IHlvdSB3b3VsZCBsaWtlIHRvIHZvbHVudGVlciwgcGxlYXNlIGNvbnNpZGVyDQp0aGF0IG5vbWNv bSBtZW1iZXJzIHBsYXkgYSB2ZXJ5IGltcG9ydGFudCByb2xlIGluIHNoYXBpbmcgdGhlIGxlYWRl cnNoaXANCm9mIHRoZSBJRVRGLiAgUXVlc3Rpb25zIGJ5IGVtYWlsIG9yIHZvaWNlIGFyZSB3ZWxj b21lLg0KVm9sdW50ZWVyaW5nIGZvciB0aGUgbm9tY29tIGlzIGEgZ3JlYXQgd2F5IHRvIGNvbnRy aWJ1dGUgdG8gdGhlIElFVEYhDQoNCllvdSBjYW4gZmluZCBhIGRldGFpbGVkIHRpbWVsaW5lIG9u IHRoZSBub21jb20gd2ViIHNpdGUgYXQ6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9ub21jb20vMjAxNC8NCg0KSSB3aWxsIGJlIHB1Ymxpc2hpbmcgYSBtb3JlIGRldGFpbGVkIHRh cmdldCB0aW1ldGFibGUsIGFzIHdlbGwgYXMgZGV0YWlscw0Kb2YgdGhlIHJhbmRvbW5lc3Mgc2Vl ZHMgdG8gYmUgdXNlZCBmb3IgdGhlIFJGQyAzNzk3IHNlbGVjdGlvbiBwcm9jZXNzLA0Kd2l0aGlu IHRoZSBuZXh0IGNvdXBsZSB3ZWVrcy4NCg0KVGhhbmsgeW91IQ0KTWljaGFlbCBSaWNoYXJkc29u DQptY3Irbm9tY29tQHNhbmRlbG1hbi5jYQ0Kbm9tY29tLWNoYWlyLTIwMTRAaWV0Zi5vcmcNCg0K PT09PT0gIHF1YWxpZmllZCB2b2x1bnRlZXJzIHNvIGZhciwgaW4gYWxwaGFiZXRpY2FsIG9yZGVy IGJ5IGZpcnN0IG5hbWUNCkFOTSBaYWhlZHV6emFtYW4gU2Fya2VyDQpBZGFtIE1vbnR2aWxsZQ0K QXJpIEtlcj9uZW4NCkJlbnNvbiBTY2hsaWVzc2VyDQpCaHVtaXAgS2hhc25hYmlzaA0KQmlsbCBW ZXJTdGVlZw0KQ2FybCBXaWxsaWFtcw0KQ2FybG9zIE1hcnRpbmV6DQpDaGFybGVzIEVja2VsDQpD aGFybGVzIFBlcmtpbnMNCkNocmlzdGVyIEhvbG1iZXJnDQpDcmFpZyBXaGl0ZQ0KREhSVVYgREhP RFkNCkRhY2hlbmcgWmhhbmcNCkRhbWllbiBTYXVjZXoNCkRhcGVuZyBMaXUNCkRlYW4gQm9nZGFu b3ZpYw0KRGltaXRyaSBQYXBhZGltaXRyaW91DQpEb25hbGQgRWFzdGxha2UNCkVkd2FyZCBDcmFi YmUNCkVtaWwgSXZvdg0KRXJpYyBSZXNjb3JsYQ0KRXJpYyBWWU5DS0UNCkZhbmd3ZWkgSHUNCkZh dGFpIFpoYW5nDQpGZXJuYW5kbyBHb250DQpGcmVkIEJha2VyDQpHaWxlcyBIZXJvbg0KR29uemFs byBTYWxndWVpcm8NCkdyZWdvcnkgTWlyc2t5DQpIYW5uZXMgR3JlZGxlcg0KSG9uZ3l1IExpDQpI b3NuaWVoIFJhZmllZQ0KSHVnbyBTYWxnYWRvDQpIdWkgRGVuZw0KSXVuaWFuYSBPcHJlc2N1DQpK ZWZmIFRhbnRzdXJhDQpKb2huIERyYWtlDQpKb2huIEphc29uIEJyem96b3dza2kNCkpvaG4gTGV2 aW5lDQpKb2huIFNjdWRkZXINCkpvbiBIdWRzb24NCkpvbiBNaXRjaGVsbA0KS2FyZW4gTydEb25v Z2h1ZQ0KS2FyZW4gU2VvDQpLYXZlaCBSYW5qYmFyDQpLbGFhcyBXaWVyZW5nYQ0KTGFycnkgTWFz aW50ZXINCkxhcnMgRWdnZXJ0DQpMZWUgSG93YXJkDQpMZWkgWmh1DQpMaSBYdWUNCkxpbmRhIER1 bmJhcg0KTGluZ2xpIERlbmcNCkxvdWlzIChMb3UpIEJlcmdlcg0KTHVjYSBNYXJ0aW5pDQpMdWN5 IEx5bmNoDQpMdWN5IFlvbmcNCkx1aWdpIElhbm5vbmUNCk1hY2ggQ2hlbg0KTWFyY2VsbyBCYWdu dWxvDQpNYXJrIFRvd25zbGV5DQpNYXR0IExlcGluc2tpDQpNYXR0aGV3IEJvY2NpDQpNZWhtZXQg RXJzdWUNCk1lbGluZGEgU2hvcmUNCk1pY2hhZWwgSm9uZXMNCk1pbiBZZQ0KTWluZ3VpIFpoYW5n DQpOaW5nIFpvbmcNCk9sZSBUcm9hbg0KUGFzY2FsIFRodWJlcnQNClBhdWwgSG9mZm1hbg0KUGV0 ZXIgTG90aGJlcmcNClBldGVyIFllZQ0KUUlOIFdVDQpSYWxwaCBEcm9tcw0KUm9uIEJvbmljYQ0K Um9zcyBDYWxsb24NClJvc3MgRmlubGF5c29uDQpSdXNzIFdoaXRlDQpTYW0gSy4gQWxkcmluDQpT YW11ZWwgV2VpbGVyDQpTYW5kZWVwIEt1bWFyDQpTYW5qYXkgTWlzaHJhDQpTY290dCBNYW5zZmll bGQNClNoZW5nIEpJQU5HDQpTaHVjaGVuZyBMaXUNClNpbW9uIFBpZXRybyBSb21hbm8NClN0YW4g UmF0bGlmZg0KU3RlcGhhbiBGcmllZGwNClN0ZXBoYW4gV2VuZ2VyDQpTdGVwaGVuIEtlbnQNClN0 ZXdhcnQgQnJ5YW50DQpTdGlnIFZlbmFhcw0KU3VoYXMgTmFuZGFrdW1hcg0KU3VyZXNoIEtyaXNo bmFuDQpTdXNhbiBIYXJlcw0KVGhvbWFzIFdhbHNoDQpUaW0gV2ljaW5za2kNClRpc3NhIFNlbmV2 aXJhdGhuZQ0KVG9lcmxlc3MgRWNrZXJ0DQpUb255IEhhbnNlbg0KVWxyaWNoIEhlcmJlcmcNClZh cnVuIFNpbmdoDQpXYXNzaW0gSGFkZGFkDQpYaWFvaHUgWFUNCllpIFpoYW8NCllpemhvdSBMaQ0K WW9uZyBDdWkNCll1YW5sb25nIEppYW5nDQpZdW5mZWkgWmhhbmcNClpoYW9odWkgWmhhbmcNClpo ZW4gQ2FvDQppdW5pYW5hIG9wcmVzY3UNCg0K From nobody Mon Jun 16 00:40: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 2CEEE1B2B79 for ; Mon, 16 Jun 2014 00:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.856 X-Spam-Level: **** X-Spam-Status: No, score=4.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=1.012, RDNS_NONE=0.793, 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 Cjn2bUPJOjqg for ; Mon, 16 Jun 2014 00:40:02 -0700 (PDT) Received: from mail.bit.edu.cn (unknown [202.204.80.7]) by ietfa.amsl.com (Postfix) with SMTP id EAEC41B2B78 for ; Mon, 16 Jun 2014 00:40:01 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 202.204.94.83 X-EMDG-VER: 4.1.1 X-EMDG-ABROAD: no Received: (eyou anti_spam gateway 4.1.0); Mon, 16 Jun 2014 15:15:34 +0800 X-EMDG-MID: <602902934.20550@mail.bit.edu.cn> Received: from 202.204.94.83 by 202.204.80.83 with SMTP; Mon, 16 Jun 2014 15:15:34 +0800 Received: from localhost ([127.0.0.1]) by bit.edu.cn with sendmail id f881ce56b8b3902d69641fd9bbb7930c; Mon, 16 Jun 2014 15:39:55 +0800 Date: Mon, 16 Jun 2014 15:39:55 +0800 From: "=?GBK?B?tcvP/sHV?=" To: tsvwg@ietf.org Message-Id: <140616153955711105008451@bit.edu.cn> MIME-Version: 1.0 X-Mailer: eYou WebMail 8.1.0.4 X-Eyou-Client: 10.15.10.47 X-Content_type: html Content-Type: multipart/alternative; boundary="9e2f78ce2f0133d40bbee0d517f9e125" Content-Transfer-Encoding: 7bit X-Eyou-Sender: Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/XkodiDvjOqSQd8fu5gnBgrQC1GA Subject: [tsvwg] =?gbk?q?FW=A3=BANew_Version_Notification_for___draft-deng?= =?gbk?q?-tsvwg-qoe-evaluation-has-00=2Etxt?= 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, 16 Jun 2014 07:40:07 -0000 --9e2f78ce2f0133d40bbee0d517f9e125 Content-Type: text/plain; charset="GBK" Content-Transfer-Encoding: base64 CkhpIGFsbCwKIApUaGUgZm9sbG93aW5nIGRyYWZ0IGlzIG5ld2x5IHN1Ym1pdHRlZCBh bmQgd2VsY29tZXMgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLgogClRoYW5rcyxYaWFv bGluIERlbmcKCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcKRGF0ZTogMjAxNC8wNi8xNgpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRlbmctdHN2d2ct cW9lLWV2YWx1YXRpb24taGFzLTAwLnR4dApUbzogIlhpYW9saW4gRGVuZyIgPHhpYW9s aW5kZW5nQGJpdC5lZHUuY24+LCAiR3VhbmdsaW4gSGFuIiA8aGFuZ3VhbmdsaW5AaHVh d2VpLmNvbT4sICJHdWFuZ2xpbiBIYW4iIDxoYW5ndWFuZ2xpbkBodWF3ZWkuY29tPiwg IlhpYW9saW4gRGVuZyIgPHhpYW9saW5kZW5nQGJpdC5lZHUuY24+CgoKCgpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGVuZy10c3Z3Zy1xb2UtZXZhbHVhdGlvbi1oYXMt MDAudHh0CgpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9saW4g RGVuZyBhbmQgcG9zdGVkIHRvIHRoZQoKSUVURiByZXBvc2l0b3J5LgoKCgpOYW1lOiBk cmFmdC1kZW5nLXRzdndnLXFvZS1ldmFsdWF0aW9uLWhhcwoKUmV2aXNpb246IDAwCgpU aXRsZTogUW9FIEV2YWx1YXRpb24gZm9yIEhUVFAgQWRhcHRpdmUgU3RyZWFtaW5nCgpE b2N1bWVudCBkYXRlOiAyMDE0LTA2LTE2CgpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNz aW9uCgpQYWdlczogNgoKVVJMOiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1kZW5nLXRzdndnLXFvZS1ldmFsdWF0aW9uLWhhcy0wMC50eHQKClN0 YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGVuZy10 c3Z3Zy1xb2UtZXZhbHVhdGlvbi1oYXMvCgpIdG1saXplZDogaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZGVuZy10c3Z3Zy1xb2UtZXZhbHVhdGlvbi1oYXMtMDAK CgoKCgpBYnN0cmFjdDoKClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRv IGV2YWx1YXRlIHRoZSBRdWFsaXR5IG9mCgpFeHBlcmllbmNlIChRb0UpIG9mIHJlYWwt dGltZSB2aWRlbyBkZWxpdmVyZWQgb3ZlciBIVFRQIEFkYXB0aXZlCgpTdHJlYW1pbmcg KEhBUykgdGVjaG5vbG9neS4gTm90IG9ubHkgdGhlIGVuZCBwb2ludHMgYnV0IGFsc28g dGhlCgpjb250ZW50IHByb3ZpZGVycyBhbmQgbmV0d29yayBvcGVyYXRvcnMgY2FuIGFj cXVpcmUgdGhlIFFvRSBvZiBIQVMgYnkKCmltcGxlbWVudGluZyB0aGlzIG1ldGhvZC4K CgoKCgoKCgoKUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbgoKdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4KCgoKVGhlIElFVEYgU2VjcmV0YXJpYXQKCgoKCiA= --9e2f78ce2f0133d40bbee0d517f9e125 Content-Type: text/html; charset="GBK" Content-Transfer-Encoding: base64 PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZm9sbG93aW5nIGRyYWZ0IGlzIG5l d2x5IHN1Ym1pdHRlZCBhbmQgd2VsY29tZXMgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPgoKPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+ClhpYW9saW4gRGVuZzxiciAvPgo8YnIgLz4KLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyIC8+CkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzxiciAvPgpEYXRlOiAyMDE0LzA2LzE2PGJyIC8+ClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGVuZy10c3Z3Zy1xb2UtZXZhbHVh dGlvbi1oYXMtMDAudHh0PGJyIC8+ClRvOiAmcXVvdDtYaWFvbGluIERlbmcmcXVvdDsg Jmx0O3hpYW9saW5kZW5nQGJpdC5lZHUuY24mZ3Q7LCAmcXVvdDtHdWFuZ2xpbiBIYW4m cXVvdDsgJmx0O2hhbmd1YW5nbGluQGh1YXdlaS5jb20mZ3Q7LCAmcXVvdDtHdWFuZ2xp biBIYW4mcXVvdDsgJmx0O2hhbmd1YW5nbGluQGh1YXdlaS5jb20mZ3Q7LCAmcXVvdDtY aWFvbGluIERlbmcmcXVvdDsgJmx0O3hpYW9saW5kZW5nQGJpdC5lZHUuY24mZ3Q7PGJy IC8+CjxiciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtZGVuZy10c3Z3Zy1xb2UtZXZhbHVhdGlvbi1oYXMtMDAudHh0PGJyIC8+ CjxiciAvPgpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9saW4g RGVuZyBhbmQgcG9zdGVkIHRvIHRoZTxiciAvPgo8YnIgLz4KSUVURiByZXBvc2l0b3J5 LjxiciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgpOYW1lOiBkcmFmdC1kZW5nLXRzdndn LXFvZS1ldmFsdWF0aW9uLWhhczxiciAvPgo8YnIgLz4KUmV2aXNpb246IDAwPGJyIC8+ CjxiciAvPgpUaXRsZTogUW9FIEV2YWx1YXRpb24gZm9yIEhUVFAgQWRhcHRpdmUgU3Ry ZWFtaW5nPGJyIC8+CjxiciAvPgpEb2N1bWVudCBkYXRlOiAyMDE0LTA2LTE2PGJyIC8+ CjxiciAvPgpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIC8+CjxiciAvPgpQ YWdlczogNjxiciAvPgo8YnIgLz4KVVJMOiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1kZW5nLXRzdndnLXFvZS1ldmFsdWF0aW9uLWhhcy0wMC50 eHQ8YnIgLz4KPGJyIC8+ClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZGVuZy10c3Z3Zy1xb2UtZXZhbHVhdGlvbi1oYXMvPGJyIC8+Cjxi ciAvPgpIdG1saXplZDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGVu Zy10c3Z3Zy1xb2UtZXZhbHVhdGlvbi1oYXMtMDA8YnIgLz4KPGJyIC8+CjxiciAvPgo8 YnIgLz4KPGJyIC8+CjxiciAvPgpBYnN0cmFjdDo8YnIgLz4KPGJyIC8+ClRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIGV2YWx1YXRlIHRoZSBRdWFsaXR5IG9m PGJyIC8+CjxiciAvPgpFeHBlcmllbmNlIChRb0UpIG9mIHJlYWwtdGltZSB2aWRlbyBk ZWxpdmVyZWQgb3ZlciBIVFRQIEFkYXB0aXZlPGJyIC8+CjxiciAvPgpTdHJlYW1pbmcg KEhBUykgdGVjaG5vbG9neS4gTm90IG9ubHkgdGhlIGVuZCBwb2ludHMgYnV0IGFsc28g dGhlPGJyIC8+CjxiciAvPgpjb250ZW50IHByb3ZpZGVycyBhbmQgbmV0d29yayBvcGVy YXRvcnMgY2FuIGFjcXVpcmUgdGhlIFFvRSBvZiBIQVMgYnk8YnIgLz4KPGJyIC8+Cmlt cGxlbWVudGluZyB0aGlzIG1ldGhvZC48YnIgLz4KPGJyIC8+CjxiciAvPgo8YnIgLz4K PGJyIC8+CjxiciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgo8YnIgLz4KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbjxiciAvPgo8YnIgLz4KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnIg Lz4KPGJyIC8+CjxiciAvPgo8YnIgLz4KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnIgLz4K PGJyIC8+CjxiciAvPgo8YnIgLz4KPGJyIC8+CiZuYnNwOw== --9e2f78ce2f0133d40bbee0d517f9e125-- From nobody Mon Jun 16 01:50: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 F18D01B29B5 for ; Mon, 16 Jun 2014 01:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-d5Ay3BZtDo for ; Mon, 16 Jun 2014 01:50:07 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7341B27EE for ; Mon, 16 Jun 2014 01:50:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,485,1400050800"; d="asc'?scan'208";a="128926992" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 16 Jun 2014 01:50:07 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 01:50:07 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 16 Jun 2014 01:50:06 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::8485:306a:80a6:ba8f%21]) with mapi id 15.00.0847.030; Mon, 16 Jun 2014 01:50:06 -0700 From: "Eggert, Lars" To: tsvwg Thread-Topic: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt Thread-Index: AQHPh7l31I2TF3KSSk2nSB2Q6S3vCw== Date: Mon, 16 Jun 2014 08:50:05 +0000 Message-ID: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4C864D03-F4FC-46E6-9EC2-056E026FA31A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/LsQUeHsSYIlOF7pINI4XEEfgtdo Subject: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.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, 16 Jun 2014 08:50:09 -0000 --Apple-Mail=_4C864D03-F4FC-46E6-9EC2-056E026FA31A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Gorry and me have started to put together an update to RFC5405 in light = of the recent discussions. Comments welcome. Lars Begin forwarded message: > From: > Subject: New Version Notification for = draft-eggert-tsvwg-rfc5405bis-00.txt > Date: June 14, 2014 at 12:14:42 GMT+2 > To: Lars Eggert , Godred Fairhurst = , Gorry Fairhurst , Lars = Eggert >=20 >=20 > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt > has been successfully submitted by Lars Eggert and posted to the > IETF repository. >=20 > Name: draft-eggert-tsvwg-rfc5405bis > Revision: 00 > Title: UDP Usage Guidelines > Document date: 2014-06-14 > Group: Individual Submission > Pages: 36 > URL: = http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt > Status: = https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ > Htmlized: = http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 >=20 >=20 > Abstract: > The User Datagram Protocol (UDP) provides a minimal message-passing > transport that has no inherent congestion control mechanisms. > Because congestion control is critical to the stable operation of = the > Internet, applications and other protocols that choose to use UDP as > an Internet transport must employ mechanisms to prevent congestion > collapse and to establish some degree of fairness with concurrent > traffic. They may also need to implement additional mechanisms, > depending on how they use UDP. >=20 > This document provides guidelines on the use of UDP for the = designers > of applications, tunnels and other protocols that use UDP. > Congestion control guidelines are a primary focus, but the document > also provides guidance on other topics, including message sizes, > reliability, checksums, and middlebox traversal. >=20 > If published as an RFC, this document will obsolete RFC5405. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_4C864D03-F4FC-46E6-9EC2-056E026FA31A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU56vvNZcnpRveo1xAQIGbwP/Qb186uRzvwGsvmbIhouQ7hI7U+psMyJV kWzh+oPAgFm2I00gui2inZ6g2QOWNVXyRjLCHc78MvaWwQGNYz5ft6VVJbyA+WHV Bn+ztJ1/pZHx0zoEZQEaJ00WmnFTJscXb9EN8yPLUxPKxP2mzpjGgm4CVdHvVx1N FmsD0bJlc5Y= =Jv+e -----END PGP SIGNATURE----- --Apple-Mail=_4C864D03-F4FC-46E6-9EC2-056E026FA31A-- From nobody Mon Jun 16 03:17:03 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 C1B2D1B2B9D for ; Mon, 16 Jun 2014 03:17:00 -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 XLJ72XhkVPQU for ; Mon, 16 Jun 2014 03:16:59 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FE71B2B54 for ; Mon, 16 Jun 2014 03:16:58 -0700 (PDT) Received: from [130.209.247.112] (port=57789 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WwTyD-0006pN-5A; Mon, 16 Jun 2014 11:16:57 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Colin Perkins In-Reply-To: <538C9AFD.2010006@erg.abdn.ac.uk> Date: Mon, 16 Jun 2014 11:16:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <538C9AFD.2010006@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/cS6uItfSU3XBgdCf65GqQ2VRz98 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Request for WG support for Circuit Breakers drfat. 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, 16 Jun 2014 10:17:00 -0000 On 2 Jun 2014, at 16:40, Gorry Fairhurst wrote: > As an individual author, to the WG (and the TSVWG Chairs): >=20 > I wrote the draft below in response to the large number of side = discussions and meeting minutes spent on this topic at the last IETF. = I=92d be very keen to see (or hear) feedback on this draft, and whether = this document could be a reasonable basis for a TSVWG document on this = topic. >=20 > http://tools.ietf.org/html/draft-fairhurst-tsvwg-circuit-breaker-01 As the author of the RTP circuit breaker draft, I think this more = general requirements and motivating discussion is valuable, and I would = support this draft becoming a TSVWG work item.=20 Cheers, Colin --=20 Colin Perkins http://csperkins.org/ From nobody Mon Jun 16 05:44:34 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 14A491A0002 for ; Mon, 16 Jun 2014 05:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zabljr1nyt3 for ; Mon, 16 Jun 2014 05:44:19 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF961A0004 for ; Mon, 16 Jun 2014 05:44:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,486,1400050800"; d="asc'?scan'208";a="128954931" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 16 Jun 2014 05:44:19 -0700 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 05:44:18 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 16 Jun 2014 05:44:06 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::8485:306a:80a6:ba8f%21]) with mapi id 15.00.0847.030; Mon, 16 Jun 2014 05:44:06 -0700 From: "Eggert, Lars" To: Colin Perkins Thread-Topic: [tsvwg] Request for WG support for Circuit Breakers drfat. Thread-Index: AQHPfnkSKFUqKIu9nk6lecAe8JsBn5t0EJaAgAApHoA= Date: Mon, 16 Jun 2014 12:44:06 +0000 Message-ID: <1604B9A0-79F7-4D06-AD94-ADCE49D4CDEF@netapp.com> References: <538C9AFD.2010006@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4D134A55-822C-4004-A1ED-32A2755734A6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/wtAjKDaWZD7g2ZWzCyfCG0yj3CM Cc: Gorry Fairhurst , "tsvwg@ietf.org" Subject: Re: [tsvwg] Request for WG support for Circuit Breakers drfat. 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, 16 Jun 2014 12:44:26 -0000 --Apple-Mail=_4D134A55-822C-4004-A1ED-32A2755734A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2014-6-16, at 12:16, Colin Perkins wrote: > I think this more general requirements and motivating discussion is = valuable, and I would support this draft becoming a TSVWG work item.=20 Agreed. (Modulo that I'm not sure that PS is the right target here. = Informational or BCP might be better.) Lars --Apple-Mail=_4D134A55-822C-4004-A1ED-32A2755734A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU57mk9ZcnpRveo1xAQJ6/AP+KcKQfVAYkb4Qe/Z/FGA5tFLiBZcCtYBg S6QkcH64sDgTV+7pJu1bXwhFCnvcULmNzBDc03uf2UAWK2K3KtwPsUT0m7FP3iW8 KZ+FtEsHUDKeSp/ITdDfAmNc2Etnq5ceyXpGY9OtjlPxjvhBoD/YGJrx0qJVWBVG I80UKbMfhYM= =KqMW -----END PGP SIGNATURE----- --Apple-Mail=_4D134A55-822C-4004-A1ED-32A2755734A6-- From nobody Mon Jun 16 11:34:39 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 0AF891A014C for ; Mon, 16 Jun 2014 11:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 IpFfMQczJqfT for ; Mon, 16 Jun 2014 11:34:34 -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 6D1FE1A013B for ; Mon, 16 Jun 2014 11:34:34 -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 637D52B4271; Mon, 16 Jun 2014 19:34:33 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Jun 2014 19:34:33 +0100 Message-ID: Date: Mon, 16 Jun 2014 19:34:33 +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/bV5ipycvpJ-8IFD4rt5qZHgZKh0 Cc: Gorry Fairhurst Subject: [tsvwg] [Fwd: Re: Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.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, 16 Jun 2014 18:34:37 -0000 I'll respond on the RTT query - since I wrote that section. I'm, not sure what you are saying, are you saying there are methods that determine how to respond to congestion that take less than one RTT, or simply the group RTT isn't an issue - maybe I'd see better with an example? Gorry > Thanks Lars. Much of this text is taken directly from my previous > draft, draft-shepherd-multicast-udp. Can you please add me to the authors > list of this draft? > > Content notes: > > Section 4.1: > > Congestion control mechanisms for multicast may operate on longer > timescales than for unicast (e.g., due to the higher group RTT of a > heterogeneous group); appropriate methods are particularly for any > multicast session were all or part of the multicast distribution tree > spans an access network (e.g., a home gateway). > > > The above isn't relevant for application based CC mechanism. In fact, an > application-based mechanism may often operate faster than any RTT > dependent > mechanism. I think we should either remove this paragraph entirely or > restructure it to make the point that application based CC operates > without > dependency on RTT. > > Greg > > > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars wrote: > >> Hi, >> >> Gorry and me have started to put together an update to RFC5405 in light >> of >> the recent discussions. Comments welcome. >> >> Lars >> >> >> Begin forwarded message: >> >> > From: >> > Subject: New Version Notification for >> draft-eggert-tsvwg-rfc5405bis-00.txt >> > Date: June 14, 2014 at 12:14:42 GMT+2 >> > To: Lars Eggert , Godred Fairhurst < >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst , Lars >> Eggert >> > >> > >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt >> > has been successfully submitted by Lars Eggert and posted to the >> > IETF repository. >> > >> > Name: draft-eggert-tsvwg-rfc5405bis >> > Revision: 00 >> > Title: UDP Usage Guidelines >> > Document date: 2014-06-14 >> > Group: Individual Submission >> > Pages: 36 >> > URL: >> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ >> > Htmlized: >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 >> > >> > >> > Abstract: >> > The User Datagram Protocol (UDP) provides a minimal message-passing >> > transport that has no inherent congestion control mechanisms. >> > Because congestion control is critical to the stable operation of >> the >> > Internet, applications and other protocols that choose to use UDP as >> > an Internet transport must employ mechanisms to prevent congestion >> > collapse and to establish some degree of fairness with concurrent >> > traffic. They may also need to implement additional mechanisms, >> > depending on how they use UDP. >> > >> > This document provides guidelines on the use of UDP for the >> designers >> > of applications, tunnels and other protocols that use UDP. >> > Congestion control guidelines are a primary focus, but the document >> > also provides guidance on other topics, including message sizes, >> > reliability, checksums, and middlebox traversal. >> > >> > If published as an RFC, this document will obsolete RFC5405. >> > >> > >> > >> > >> > Please note that it may take a couple of minutes from the time of >> submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > The IETF Secretariat >> > >> >> > From nobody Mon Jun 16 12:36: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 B61DE1A0179 for ; Mon, 16 Jun 2014 12:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 u0wrMMmR7HVq for ; Mon, 16 Jun 2014 12:35:42 -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 4C8F61A0169 for ; Mon, 16 Jun 2014 12:35:42 -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 2F5BB2B4271; Mon, 16 Jun 2014 20:35:41 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Jun 2014 20:35:41 +0100 Message-ID: <3ff3245f2b9711f104e80f6ed528dc3a.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 20:35:41 +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/quNKt-a-FQaedeY-rpXnTs2TUE8 Cc: Gorry Fairhurst Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.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, 16 Jun 2014 19:35:49 -0000 > See-in-line >> On Mon, Jun 16, 2014 at 11:33 AM, wrote: >> >>> I'll respond on the RTT query - since I wrote that section. >>> >>> I'm, not sure what you are saying, are you saying there are methods >>> that >>> determine how to respond to congestion that take less than one RTT, or >>> simply the group RTT isn't an issue - maybe I'd see better with an >>> example? >> >> >> Right, the whole concept of RTT is irrelevant here since there is no >> message round trip from receiver to source and back. The CC >> determination >> (channel selection/combination) is determined by the application without >> upstream signaling at all. That was the point of the last sentence in >> the >> previous paragraph which came from section 2.1 of my >> draft draft-shepherd-multicast-udp-guidelines-01.txt >> > I had some doubt about that part: Let me see if I can explain what I am > thinking: > > - For example, using ALC, I'd have expected loss due to congestion at a > bottleneck to result in each receiver downstream of the bottleneck in > reducing the group membership for the higher-rate streams, but the > required rate reduction takes a little while to propagate up the (PIM) > multicast distribution tree, and the source only ceases when there are no > further subscriptions (or timeout). > > Whatever, ALC would take at least a RTT to the furthest receiver (with > loss) that has subscribed to the group, before the source has a chance to > reduce the load on the bottleneck. > > I know you could also immediately react to loss (aka NORM), but then that > would prevent heterogenous operation where one part of the group can > receive faster than others. This reaction is more conservative from a CC > viewpoint > > Gorry > >> Greg >> >> >> >>> >>> Gorry >>> >>> >>> > Thanks Lars. Much of this text is taken directly from my previous >>> > draft, draft-shepherd-multicast-udp. Can you please add me to the >>> authors >>> > list of this draft? >>> > >>> > Content notes: >>> > >>> > Section 4.1: >>> > >>> > Congestion control mechanisms for multicast may operate on longer >>> > timescales than for unicast (e.g., due to the higher group RTT of >>> a >>> > heterogeneous group); appropriate methods are particularly for any >>> > multicast session were all or part of the multicast distribution >>> tree >>> > spans an access network (e.g., a home gateway). >>> > >>> > >>> > The above isn't relevant for application based CC mechanism. In fact, >>> an >>> > application-based mechanism may often operate faster than any RTT >>> > dependent >>> > mechanism. I think we should either remove this paragraph entirely or >>> > restructure it to make the point that application based CC operates >>> > without >>> > dependency on RTT. >>> > >>> > Greg >>> > >>> > >>> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars >>> wrote: >>> > >>> >> Hi, >>> >> >>> >> Gorry and me have started to put together an update to RFC5405 in >>> light >>> >> of >>> >> the recent discussions. Comments welcome. >>> >> >>> >> Lars >>> >> >>> >> >>> >> Begin forwarded message: >>> >> >>> >> > From: >>> >> > Subject: New Version Notification for >>> >> draft-eggert-tsvwg-rfc5405bis-00.txt >>> >> > Date: June 14, 2014 at 12:14:42 GMT+2 >>> >> > To: Lars Eggert , Godred Fairhurst < >>> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst , Lars >>> >> Eggert >>> >> > >>> >> > >>> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt >>> >> > has been successfully submitted by Lars Eggert and posted to the >>> >> > IETF repository. >>> >> > >>> >> > Name: draft-eggert-tsvwg-rfc5405bis >>> >> > Revision: 00 >>> >> > Title: UDP Usage Guidelines >>> >> > Document date: 2014-06-14 >>> >> > Group: Individual Submission >>> >> > Pages: 36 >>> >> > URL: >>> >> >>> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt >>> >> > Status: >>> >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ >>> >> > Htmlized: >>> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 >>> >> > >>> >> > >>> >> > Abstract: >>> >> > The User Datagram Protocol (UDP) provides a minimal >>> message-passing >>> >> > transport that has no inherent congestion control mechanisms. >>> >> > Because congestion control is critical to the stable operation >>> of >>> >> the >>> >> > Internet, applications and other protocols that choose to use >>> UDP >>> as >>> >> > an Internet transport must employ mechanisms to prevent >>> congestion >>> >> > collapse and to establish some degree of fairness with >>> concurrent >>> >> > traffic. They may also need to implement additional mechanisms, >>> >> > depending on how they use UDP. >>> >> > >>> >> > This document provides guidelines on the use of UDP for the >>> >> designers >>> >> > of applications, tunnels and other protocols that use UDP. >>> >> > Congestion control guidelines are a primary focus, but the >>> document >>> >> > also provides guidance on other topics, including message sizes, >>> >> > reliability, checksums, and middlebox traversal. >>> >> > >>> >> > If published as an RFC, this document will obsolete RFC5405. >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > Please note that it may take a couple of minutes from the time of >>> >> submission >>> >> > until the htmlized version and diff are available at >>> tools.ietf.org. >>> >> > >>> >> > The IETF Secretariat >>> >> > >>> >> >>> >> >>> > >>> >>> >>> >> > > From nobody Mon Jun 16 13:12:59 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 85C591A01C8 for ; Mon, 16 Jun 2014 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 wAYf6ctRGUom for ; Mon, 16 Jun 2014 13:12:56 -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 B36D51A01C7 for ; Mon, 16 Jun 2014 13:12:55 -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 89AB92B4271; Mon, 16 Jun 2014 21:12:54 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Jun 2014 21:12:54 +0100 Message-ID: In-Reply-To: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 21:12:54 +0100 From: gorry@erg.abdn.ac.uk To: gjshep@gmail.com 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/IH3Y7kDOXw537pS0CfDtq6hJ4aQ Cc: Gorry Fairhurst , tsvwg@ietf.org Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.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, 16 Jun 2014 20:12:57 -0000 In-line > Inline: > > On Mon, Jun 16, 2014 at 12:34 PM, wrote: > >> See-in-line >> > On Mon, Jun 16, 2014 at 11:33 AM, wrote: >> > >> >> I'll respond on the RTT query - since I wrote that section. >> >> >> >> I'm, not sure what you are saying, are you saying there are methods >> that >> >> determine how to respond to congestion that take less than one RTT, >> or >> >> simply the group RTT isn't an issue - maybe I'd see better with an >> >> example? >> > >> > >> > Right, the whole concept of RTT is irrelevant here since there is no >> > message round trip from receiver to source and back. The CC >> determination >> > (channel selection/combination) is determined by the application >> without >> > upstream signaling at all. That was the point of the last sentence in >> the >> > previous paragraph which came from section 2.1 of my >> > draft draft-shepherd-multicast-udp-guidelines-01.txt >> > >> I had some doubt about that part: Let me see if I can explain what I am >> thinking: >> >> - For example, using ALC, I'd have expected loss due to congestion at a >> bottleneck to result in each receiver downstream of the bottleneck in >> reducing the group membership for the higher-rate streams, but the >> required rate reduction takes a little while to propagate up the (PIM) >> multicast distribution tree, and the source only ceases when there are >> no >> further subscriptions (or timeout). >> > > We're already gone off track here; RTT is just a measure of time. It > doesn't itself directly refer to any form of CC. Join latency is not RTT. > WEBRC coined the term MRTT in an attempt to tie join-latency to the > concept > of RTT as it applies to CC. > I don't agree - even though there may be no "RTT timer", the largest round trip time of any receiver in the ALC group is still the parameter that controls the responsiveness of the CC mechanism. > >> Whatever, ALC would take at least a RTT to the furthest receiver (with >> loss) that has subscribed to the group, before the source has a chance >> to >> reduce the load on the bottleneck. >> > > I don't believe ALC sources change rates at all. There is a rate/group > profile which the receiver application side selects. > I should have been clearer, the rate at which the source injects traffic into the congested bottleneck queue. The rate at which the ALC source feeds this queue varies as the subscription to higher-rate groups subside. > >> I know you could also immediately react to loss (aka NORM), but then >> that >> would prevent heterogenous operation where one part of the group can >> receive faster than others. This reaction is more conservative from a CC >> viewpoint > > > ..which goes into the description of various CC mechanisms and departs > from > any applicability of RTT. > > Greg > Gorry > >> >> Gorry >> >> > Greg >> > >> > >> > >> >> >> >> Gorry >> >> >> >> >> >> > Thanks Lars. Much of this text is taken directly from my previous >> >> > draft, draft-shepherd-multicast-udp. Can you please add me to the >> >> authors >> >> > list of this draft? >> >> > >> >> > Content notes: >> >> > >> >> > Section 4.1: >> >> > >> >> > Congestion control mechanisms for multicast may operate on longer >> >> > timescales than for unicast (e.g., due to the higher group RTT >> of a >> >> > heterogeneous group); appropriate methods are particularly for >> any >> >> > multicast session were all or part of the multicast distribution >> >> tree >> >> > spans an access network (e.g., a home gateway). >> >> > >> >> > >> >> > The above isn't relevant for application based CC mechanism. In >> fact, >> >> an >> >> > application-based mechanism may often operate faster than any RTT >> >> > dependent >> >> > mechanism. I think we should either remove this paragraph entirely >> or >> >> > restructure it to make the point that application based CC operates >> >> > without >> >> > dependency on RTT. >> >> > >> >> > Greg >> >> > >> >> > >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars >> wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> Gorry and me have started to put together an update to RFC5405 in >> >> light >> >> >> of >> >> >> the recent discussions. Comments welcome. >> >> >> >> >> >> Lars >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> >> >> >> >> > From: >> >> >> > Subject: New Version Notification for >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2 >> >> >> > To: Lars Eggert , Godred Fairhurst < >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst , >> Lars >> >> >> Eggert >> >> >> > >> >> >> > >> >> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> > has been successfully submitted by Lars Eggert and posted to the >> >> >> > IETF repository. >> >> >> > >> >> >> > Name: draft-eggert-tsvwg-rfc5405bis >> >> >> > Revision: 00 >> >> >> > Title: UDP Usage Guidelines >> >> >> > Document date: 2014-06-14 >> >> >> > Group: Individual Submission >> >> >> > Pages: 36 >> >> >> > URL: >> >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> > Status: >> >> >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ >> >> >> > Htmlized: >> >> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 >> >> >> > >> >> >> > >> >> >> > Abstract: >> >> >> > The User Datagram Protocol (UDP) provides a minimal >> >> message-passing >> >> >> > transport that has no inherent congestion control mechanisms. >> >> >> > Because congestion control is critical to the stable operation >> of >> >> >> the >> >> >> > Internet, applications and other protocols that choose to use >> UDP >> >> as >> >> >> > an Internet transport must employ mechanisms to prevent >> >> congestion >> >> >> > collapse and to establish some degree of fairness with >> concurrent >> >> >> > traffic. They may also need to implement additional >> mechanisms, >> >> >> > depending on how they use UDP. >> >> >> > >> >> >> > This document provides guidelines on the use of UDP for the >> >> >> designers >> >> >> > of applications, tunnels and other protocols that use UDP. >> >> >> > Congestion control guidelines are a primary focus, but the >> >> document >> >> >> > also provides guidance on other topics, including message >> sizes, >> >> >> > reliability, checksums, and middlebox traversal. >> >> >> > >> >> >> > If published as an RFC, this document will obsolete RFC5405. >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > Please note that it may take a couple of minutes from the time >> of >> >> >> submission >> >> >> > until the htmlized version and diff are available at >> >> tools.ietf.org. >> >> >> > >> >> >> > The IETF Secretariat >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> > From nobody Mon Jun 16 13:19: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 042D61A01F9 for ; Mon, 16 Jun 2014 13:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 2Ic1AQhaHZJQ for ; Mon, 16 Jun 2014 13:19:10 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D101A01DD for ; Mon, 16 Jun 2014 13:19:09 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so4715020wiw.5 for ; Mon, 16 Jun 2014 13:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zp6DWF92iRitdBQ4n3dXEJIUIEuXygTvMLhbi5VhgwE=; b=n6TEM9hxReTDs7ODjOlDIXOvONt19jQ7UMSkuXL5WEoHtMcDHTFZP3M5D6Sd6D3WAG xg3v6Ulv00V0oiKexmG17fIn/JEUbMVTjrMHw4B00zfReK94s3pPZSUzjkuC/GtSEQVF +wsdwcQu8rgw4LXgCC1UWpd6p8cVxmNmBme4psH7Hmrn6J0KmZa0tw6gQPCzwhDjrp7B bWBUGcvJY+D/avZQewcnWVrXRigqukZN9wacOCxA5uxD18/bkCObHqU5f3gHxUmJec8M ymYymFCygAQXczcR0Ywd+/cxIqi2tuhbdF79TUnJeplOOEBh4MGcIiM7j07x1deSpja2 fseQ== MIME-Version: 1.0 X-Received: by 10.194.1.242 with SMTP id 18mr32366283wjp.22.1402949948329; Mon, 16 Jun 2014 13:19:08 -0700 (PDT) Received: by 10.180.21.211 with HTTP; Mon, 16 Jun 2014 13:19:08 -0700 (PDT) In-Reply-To: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 13:19:08 -0700 Message-ID: From: Greg Shepherd To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=047d7b3a82144ed53704fbf9bdd9 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/_lTavrc6y9GCHqAgP6SydiHRlLg Cc: "" Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:19:17 -0000 --047d7b3a82144ed53704fbf9bdd9 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 16, 2014 at 1:12 PM, wrote: > In-line > > > Inline: > > > > On Mon, Jun 16, 2014 at 12:34 PM, wrote: > > > >> See-in-line > >> > On Mon, Jun 16, 2014 at 11:33 AM, wrote: > >> > > >> >> I'll respond on the RTT query - since I wrote that section. > >> >> > >> >> I'm, not sure what you are saying, are you saying there are methods > >> that > >> >> determine how to respond to congestion that take less than one RTT, > >> or > >> >> simply the group RTT isn't an issue - maybe I'd see better with an > >> >> example? > >> > > >> > > >> > Right, the whole concept of RTT is irrelevant here since there is no > >> > message round trip from receiver to source and back. The CC > >> determination > >> > (channel selection/combination) is determined by the application > >> without > >> > upstream signaling at all. That was the point of the last sentence in > >> the > >> > previous paragraph which came from section 2.1 of my > >> > draft draft-shepherd-multicast-udp-guidelines-01.txt > >> > > >> I had some doubt about that part: Let me see if I can explain what I am > >> thinking: > >> > >> - For example, using ALC, I'd have expected loss due to congestion at a > >> bottleneck to result in each receiver downstream of the bottleneck in > >> reducing the group membership for the higher-rate streams, but the > >> required rate reduction takes a little while to propagate up the (PIM) > >> multicast distribution tree, and the source only ceases when there are > >> no > >> further subscriptions (or timeout). > >> > > > > We're already gone off track here; RTT is just a measure of time. It > > doesn't itself directly refer to any form of CC. Join latency is not RTT. > > WEBRC coined the term MRTT in an attempt to tie join-latency to the > > concept > > of RTT as it applies to CC. > > > I don't agree - even though there may be no "RTT timer", the largest round > trip time of any receiver in the ALC group is still the parameter that > controls the responsiveness of the CC mechanism. Almost right.. It's not any round trip time. It's join/leave latency. I'm not arguing the mechanism, I'm arguing the term. We need to be clear - there is not control RTT like TCP here. > > > >> Whatever, ALC would take at least a RTT to the furthest receiver (with > >> loss) that has subscribed to the group, before the source has a chance > >> to > >> reduce the load on the bottleneck. > >> > > > > I don't believe ALC sources change rates at all. There is a rate/group > > profile which the receiver application side selects. > > > I should have been clearer, the rate at which the source injects traffic > into the congested bottleneck queue. The rate at which the ALC source > feeds this queue varies as the subscription to higher-rate groups subside. Sure, but this is a topology dependency and no application will be able to respond to where congestion occurs, only if/when they see congestion directly. Just like TCP - it has no clue where congestion occurs. It just reacts to local detection. Greg > > > >> I know you could also immediately react to loss (aka NORM), but then > >> that > >> would prevent heterogenous operation where one part of the group can > >> receive faster than others. This reaction is more conservative from a CC > >> viewpoint > > > > > > ..which goes into the description of various CC mechanisms and departs > > from > > any applicability of RTT. > > > > Greg > > > > > Gorry > > > >> > >> Gorry > >> > >> > Greg > >> > > >> > > >> > > >> >> > >> >> Gorry > >> >> > >> >> > >> >> > Thanks Lars. Much of this text is taken directly from my previous > >> >> > draft, draft-shepherd-multicast-udp. Can you please add me to the > >> >> authors > >> >> > list of this draft? > >> >> > > >> >> > Content notes: > >> >> > > >> >> > Section 4.1: > >> >> > > >> >> > Congestion control mechanisms for multicast may operate on longer > >> >> > timescales than for unicast (e.g., due to the higher group RTT > >> of a > >> >> > heterogeneous group); appropriate methods are particularly for > >> any > >> >> > multicast session were all or part of the multicast distribution > >> >> tree > >> >> > spans an access network (e.g., a home gateway). > >> >> > > >> >> > > >> >> > The above isn't relevant for application based CC mechanism. In > >> fact, > >> >> an > >> >> > application-based mechanism may often operate faster than any RTT > >> >> > dependent > >> >> > mechanism. I think we should either remove this paragraph entirely > >> or > >> >> > restructure it to make the point that application based CC operates > >> >> > without > >> >> > dependency on RTT. > >> >> > > >> >> > Greg > >> >> > > >> >> > > >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars > >> wrote: > >> >> > > >> >> >> Hi, > >> >> >> > >> >> >> Gorry and me have started to put together an update to RFC5405 in > >> >> light > >> >> >> of > >> >> >> the recent discussions. Comments welcome. > >> >> >> > >> >> >> Lars > >> >> >> > >> >> >> > >> >> >> Begin forwarded message: > >> >> >> > >> >> >> > From: > >> >> >> > Subject: New Version Notification for > >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2 > >> >> >> > To: Lars Eggert , Godred Fairhurst < > >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst , > >> Lars > >> >> >> Eggert > >> >> >> > > >> >> >> > > >> >> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> > has been successfully submitted by Lars Eggert and posted to the > >> >> >> > IETF repository. > >> >> >> > > >> >> >> > Name: draft-eggert-tsvwg-rfc5405bis > >> >> >> > Revision: 00 > >> >> >> > Title: UDP Usage Guidelines > >> >> >> > Document date: 2014-06-14 > >> >> >> > Group: Individual Submission > >> >> >> > Pages: 36 > >> >> >> > URL: > >> >> >> > >> >> > >> > http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> > Status: > >> >> >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ > >> >> >> > Htmlized: > >> >> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 > >> >> >> > > >> >> >> > > >> >> >> > Abstract: > >> >> >> > The User Datagram Protocol (UDP) provides a minimal > >> >> message-passing > >> >> >> > transport that has no inherent congestion control mechanisms. > >> >> >> > Because congestion control is critical to the stable operation > >> of > >> >> >> the > >> >> >> > Internet, applications and other protocols that choose to use > >> UDP > >> >> as > >> >> >> > an Internet transport must employ mechanisms to prevent > >> >> congestion > >> >> >> > collapse and to establish some degree of fairness with > >> concurrent > >> >> >> > traffic. They may also need to implement additional > >> mechanisms, > >> >> >> > depending on how they use UDP. > >> >> >> > > >> >> >> > This document provides guidelines on the use of UDP for the > >> >> >> designers > >> >> >> > of applications, tunnels and other protocols that use UDP. > >> >> >> > Congestion control guidelines are a primary focus, but the > >> >> document > >> >> >> > also provides guidance on other topics, including message > >> sizes, > >> >> >> > reliability, checksums, and middlebox traversal. > >> >> >> > > >> >> >> > If published as an RFC, this document will obsolete RFC5405. > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Please note that it may take a couple of minutes from the time > >> of > >> >> >> submission > >> >> >> > until the htmlized version and diff are available at > >> >> tools.ietf.org. > >> >> >> > > >> >> >> > The IETF Secretariat > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> >> > >> > > >> > >> > >> > > > > > --047d7b3a82144ed53704fbf9bdd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 16, 2014 at 1:1= 2 PM, <gorry@erg.abdn.ac.uk> wrote:
In-line

> Inline:
>
> On Mon, Jun 16, 2014 at 12:34 PM, <gorry@erg.abdn.ac.uk> wrote:
>
>> See-in-line
>> > On Mon, Jun 16, 2014 at 11:33 AM, <gorry@erg.abdn.ac.uk> wrote:
>> >
>> >> I'll respond on the RTT query - since I wrote that se= ction.
>> >>
>> >> I'm, not sure what you are saying, are you saying the= re are methods
>> that
>> >> determine how to respond to congestion that take less tha= n one RTT,
>> or
>> >> simply the group RTT isn't an issue - maybe I'd s= ee better with an
>> >> example?
>> >
>> >
>> > Right, the whole concept of RTT is irrelevant here since ther= e is no
>> > message round trip from receiver to source and back. The CC >> determination
>> > (channel selection/combination) is determined by the applicat= ion
>> without
>> > upstream signaling at all. That was the point of the last sen= tence in
>> the
>> > previous paragraph which came from section 2.1 of my
>> > draft draft-shepherd-multicast-udp-guidelines-01.txt
>> >
>> I had some doubt about that part: Let me see if I can explain what= I am
>> thinking:
>>
>> - For example, using ALC, I'd have expected loss due to conges= tion at a
>> bottleneck to result in =C2=A0each receiver downstream of the bott= leneck in
>> reducing the group membership for the higher-rate streams, but the=
>> required rate reduction takes a little while to propagate up the (= PIM)
>> multicast distribution tree, and the source only ceases when there= are
>> no
>> further subscriptions (or timeout).
>>
>
> We're already gone off track here; RTT is just a measure of time. = It
> doesn't itself directly refer to any form of CC. Join latency is n= ot RTT.
> WEBRC coined the term MRTT in an attempt to tie join-latency to the > concept
> of RTT as it applies to CC.
>
I don't agree - even though there may be no "RTT timer= ", the largest round
trip time of any receiver in the ALC group is still the parameter that
controls the responsiveness of the CC mechanism.

Almost right.. It's not any round trip time. It's join/leave = latency. I'm not arguing the mechanism, I'm arguing the term. We ne= ed to be clear - there is not control RTT like TCP here.=C2=A0
=C2=A0
>
>> Whatever, ALC would take at least a RTT to the furthest receiver (= with
>> loss) that has subscribed to the group, before the source has a ch= ance
>> to
>> reduce the load on the bottleneck.
>>
>
> I don't believe ALC sources change rates at all. There is a rate/g= roup
> profile which the receiver application side selects.
>
I should have been clearer, the rate at which the source injects traf= fic
into the congested bottleneck queue. The rate at which the ALC source
feeds this queue varies as the subscription to higher-rate groups subside.<= /blockquote>

Sure, but this is a topology dependency and= no application will be able to respond to where congestion occurs, only if= /when they see congestion directly. Just like TCP - it has no clue where co= ngestion occurs. It just reacts to local detection.

Greg
=C2=A0
>
>> I know you could also immediately react to loss (aka NORM), but th= en
>> that
>> would prevent heterogenous operation where one part of the group c= an
>> receive faster than others. This reaction is more conservative fro= m a CC
>> viewpoint
>
>
> ..which goes into the description of various CC mechanisms and departs=
> from
> any applicability of RTT.
>
> Greg
>


Gorry
>
>>
>> Gorry
>>
>> > Greg
>> >
>> >
>> >
>> >>
>> >> Gorry
>> >>
>> >>
>> >> > Thanks Lars. Much of this text is taken directly fro= m my previous
>> >> > draft, draft-shepherd-multicast-udp. Can you please = add me to the
>> >> authors
>> >> > list of this draft?
>> >> >
>> >> > Content notes:
>> >> >
>> >> > Section 4.1:
>> >> >
>> >> > Congestion control mechanisms for multicast may oper= ate on longer
>> >> > =C2=A0 =C2=A0timescales than for unicast (e.g., due = to the higher group RTT
>> of a
>> >> > =C2=A0 =C2=A0heterogeneous group); appropriate metho= ds are particularly for
>> any
>> >> > =C2=A0 =C2=A0multicast session were all or part of t= he multicast distribution
>> >> tree
>> >> > =C2=A0 =C2=A0spans an access network (e.g., a home g= ateway).
>> >> >
>> >> >
>> >> > The above isn't relevant for application based C= C mechanism. In
>> fact,
>> >> an
>> >> > application-based mechanism may often operate faster= than any RTT
>> >> > dependent
>> >> > mechanism. I think we should either remove this para= graph entirely
>> or
>> >> > restructure it to make the point that application ba= sed CC operates
>> >> > without
>> >> > dependency on RTT.
>> >> >
>> >> > Greg
>> >> >
>> >> >
>> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars <lars@netapp.com>
>> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> Gorry and me have started to put together an upd= ate to RFC5405 in
>> >> light
>> >> >> of
>> >> >> the recent discussions. Comments welcome.
>> >> >>
>> >> >> Lars
>> >> >>
>> >> >>
>> >> >> Begin forwarded message:
>> >> >>
>> >> >> > From: <internet-drafts@ietf.org>
>> >> >> > Subject: New Version Notification for
>> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt
>> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2
>> >> >> > To: Lars Eggert <lars@netapp.com>, Godred Fairhurst <
>> >> >> gorry@er= g.abdn.ac.uk>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>,
>> Lars
>> >> >> Eggert <la= rs@netapp.com>
>> >> >> >
>> >> >> >
>> >> >> > A new version of I-D, draft-eggert-tsvwg-rf= c5405bis-00.txt
>> >> >> > has been successfully submitted by Lars Egg= ert and posted to the
>> >> >> > IETF repository.
>> >> >> >
>> >> >> > Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-egg= ert-tsvwg-rfc5405bis
>> >> >> > Revision: =C2=A0 =C2=A0 00
>> >> >> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0UDP Usage Guidelines
>> >> >> > Document date: =C2=A0 =C2=A0 =C2=A0 =C2=A02= 014-06-14
>> >> >> > Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Individual Submission
>> >> >> > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A036
>> >> >> > URL:
>> >> >>
>> >>
>> http://www.ietf.org/internet-drafts/dr= aft-eggert-tsvwg-rfc5405bis-00.txt
>> >> >> > Status:
>> >> >> https://datatracker.ietf.org/= doc/draft-eggert-tsvwg-rfc5405bis/
>> >> >> > Htmlized:
>> >> >> http://tools.ietf.org/html/draft-= eggert-tsvwg-rfc5405bis-00
>> >> >> >
>> >> >> >
>> >> >> > Abstract:
>> >> >> > =C2=A0 The User Datagram Protocol (UDP) pro= vides a minimal
>> >> message-passing
>> >> >> > =C2=A0 transport that has no inherent conge= stion control mechanisms.
>> >> >> > =C2=A0 Because congestion control is critic= al to the stable operation
>> of
>> >> >> the
>> >> >> > =C2=A0 Internet, applications and other pro= tocols that choose to use
>> UDP
>> >> as
>> >> >> > =C2=A0 an Internet transport must employ me= chanisms to prevent
>> >> congestion
>> >> >> > =C2=A0 collapse and to establish some degre= e of fairness with
>> concurrent
>> >> >> > =C2=A0 traffic. =C2=A0They may also need to= implement additional
>> mechanisms,
>> >> >> > =C2=A0 depending on how they use UDP.
>> >> >> >
>> >> >> > =C2=A0 This document provides guidelines on= the use of UDP for the
>> >> >> designers
>> >> >> > =C2=A0 of applications, tunnels and other p= rotocols that use UDP.
>> >> >> > =C2=A0 Congestion control guidelines are a = primary focus, but the
>> >> document
>> >> >> > =C2=A0 also provides guidance on other topi= cs, including message
>> sizes,
>> >> >> > =C2=A0 reliability, checksums, and middlebo= x traversal.
>> >> >> >
>> >> >> > =C2=A0 If published as an RFC, this documen= t will obsolete RFC5405.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Please note that it may take a couple of mi= nutes from the time
>> of
>> >> >> submission
>> >> >> > until the htmlized version and diff are ava= ilable at
>> >> tools= .ietf.org.
>> >> >> >
>> >> >> > The IETF Secretariat
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



--047d7b3a82144ed53704fbf9bdd9-- From nobody Mon Jun 16 13:31:12 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 9D1351A01F9 for ; Mon, 16 Jun 2014 13:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 a8aDf5nImFsX for ; Mon, 16 Jun 2014 13:31:08 -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 412C81A01F5 for ; Mon, 16 Jun 2014 13:31:08 -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 2F6602B4271; Mon, 16 Jun 2014 21:31:07 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Jun 2014 21:31:07 +0100 Message-ID: <193fa185d1c175afed42ac03e966a0b0.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 21:31:07 +0100 From: gorry@erg.abdn.ac.uk To: gjshep@gmail.com 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/BWjw0fccF5LBazev9-sy4sMZqgI Cc: Gorry Fairhurst , tsvwg@ietf.org Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.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, 16 Jun 2014 20:31:10 -0000 So, basically, ALC doesn't mention RTT, but NORM does. Both of these react on larger time scales than TCP would have reacted to the same congestion event. So if we remove RTT is this OK: Section 4.1: Congestion control mechanisms for multicast may operate on longer timescales than for unicast (especially where group members have widely different path delays). Appropriate methods are particularly important for any multicast session were all or part of the multicast distribution tree spans an access network (e.g., a home gateway). Gorry > On Mon, Jun 16, 2014 at 1:12 PM, wrote: > >> In-line >> >> > Inline: >> > >> > On Mon, Jun 16, 2014 at 12:34 PM, wrote: >> > >> >> See-in-line >> >> > On Mon, Jun 16, 2014 at 11:33 AM, wrote: >> >> > >> >> >> I'll respond on the RTT query - since I wrote that section. >> >> >> >> >> >> I'm, not sure what you are saying, are you saying there are >> methods >> >> that >> >> >> determine how to respond to congestion that take less than one >> RTT, >> >> or >> >> >> simply the group RTT isn't an issue - maybe I'd see better with an >> >> >> example? >> >> > >> >> > >> >> > Right, the whole concept of RTT is irrelevant here since there is >> no >> >> > message round trip from receiver to source and back. The CC >> >> determination >> >> > (channel selection/combination) is determined by the application >> >> without >> >> > upstream signaling at all. That was the point of the last sentence >> in >> >> the >> >> > previous paragraph which came from section 2.1 of my >> >> > draft draft-shepherd-multicast-udp-guidelines-01.txt >> >> > >> >> I had some doubt about that part: Let me see if I can explain what I >> am >> >> thinking: >> >> >> >> - For example, using ALC, I'd have expected loss due to congestion at >> a >> >> bottleneck to result in each receiver downstream of the bottleneck >> in >> >> reducing the group membership for the higher-rate streams, but the >> >> required rate reduction takes a little while to propagate up the >> (PIM) >> >> multicast distribution tree, and the source only ceases when there >> are >> >> no >> >> further subscriptions (or timeout). >> >> >> > >> > We're already gone off track here; RTT is just a measure of time. It >> > doesn't itself directly refer to any form of CC. Join latency is not >> RTT. >> > WEBRC coined the term MRTT in an attempt to tie join-latency to the >> > concept >> > of RTT as it applies to CC. >> > >> I don't agree - even though there may be no "RTT timer", the largest >> round >> trip time of any receiver in the ALC group is still the parameter that >> controls the responsiveness of the CC mechanism. > > > Almost right.. It's not any round trip time. It's join/leave latency. I'm > not arguing the mechanism, I'm arguing the term. We need to be clear - > there is not control RTT like TCP here. > > >> > >> >> Whatever, ALC would take at least a RTT to the furthest receiver >> (with >> >> loss) that has subscribed to the group, before the source has a >> chance >> >> to >> >> reduce the load on the bottleneck. >> >> >> > >> > I don't believe ALC sources change rates at all. There is a rate/group >> > profile which the receiver application side selects. >> > >> I should have been clearer, the rate at which the source injects traffic >> into the congested bottleneck queue. The rate at which the ALC source >> feeds this queue varies as the subscription to higher-rate groups >> subside. > > > Sure, but this is a topology dependency and no application will be able to > respond to where congestion occurs, only if/when they see congestion > directly. Just like TCP - it has no clue where congestion occurs. It just > reacts to local detection. > > Greg > > >> > >> >> I know you could also immediately react to loss (aka NORM), but then >> >> that >> >> would prevent heterogenous operation where one part of the group can >> >> receive faster than others. This reaction is more conservative from a >> CC >> >> viewpoint >> > >> > >> > ..which goes into the description of various CC mechanisms and departs >> > from >> > any applicability of RTT. >> > >> > Greg >> > >> >> >> Gorry >> > >> >> >> >> Gorry >> >> >> >> > Greg >> >> > >> >> > >> >> > >> >> >> >> >> >> Gorry >> >> >> >> >> >> >> >> >> > Thanks Lars. Much of this text is taken directly from my >> previous >> >> >> > draft, draft-shepherd-multicast-udp. Can you please add me to >> the >> >> >> authors >> >> >> > list of this draft? >> >> >> > >> >> >> > Content notes: >> >> >> > >> >> >> > Section 4.1: >> >> >> > >> >> >> > Congestion control mechanisms for multicast may operate on >> longer >> >> >> > timescales than for unicast (e.g., due to the higher group >> RTT >> >> of a >> >> >> > heterogeneous group); appropriate methods are particularly >> for >> >> any >> >> >> > multicast session were all or part of the multicast >> distribution >> >> >> tree >> >> >> > spans an access network (e.g., a home gateway). >> >> >> > >> >> >> > >> >> >> > The above isn't relevant for application based CC mechanism. In >> >> fact, >> >> >> an >> >> >> > application-based mechanism may often operate faster than any >> RTT >> >> >> > dependent >> >> >> > mechanism. I think we should either remove this paragraph >> entirely >> >> or >> >> >> > restructure it to make the point that application based CC >> operates >> >> >> > without >> >> >> > dependency on RTT. >> >> >> > >> >> >> > Greg >> >> >> > >> >> >> > >> >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars >> >> wrote: >> >> >> > >> >> >> >> Hi, >> >> >> >> >> >> >> >> Gorry and me have started to put together an update to RFC5405 >> in >> >> >> light >> >> >> >> of >> >> >> >> the recent discussions. Comments welcome. >> >> >> >> >> >> >> >> Lars >> >> >> >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> >> >> >> >> >> >> > From: >> >> >> >> > Subject: New Version Notification for >> >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2 >> >> >> >> > To: Lars Eggert , Godred Fairhurst < >> >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst , >> >> Lars >> >> >> >> Eggert >> >> >> >> > >> >> >> >> > >> >> >> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> > has been successfully submitted by Lars Eggert and posted to >> the >> >> >> >> > IETF repository. >> >> >> >> > >> >> >> >> > Name: draft-eggert-tsvwg-rfc5405bis >> >> >> >> > Revision: 00 >> >> >> >> > Title: UDP Usage Guidelines >> >> >> >> > Document date: 2014-06-14 >> >> >> >> > Group: Individual Submission >> >> >> >> > Pages: 36 >> >> >> >> > URL: >> >> >> >> >> >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> > Status: >> >> >> >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ >> >> >> >> > Htmlized: >> >> >> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 >> >> >> >> > >> >> >> >> > >> >> >> >> > Abstract: >> >> >> >> > The User Datagram Protocol (UDP) provides a minimal >> >> >> message-passing >> >> >> >> > transport that has no inherent congestion control >> mechanisms. >> >> >> >> > Because congestion control is critical to the stable >> operation >> >> of >> >> >> >> the >> >> >> >> > Internet, applications and other protocols that choose to >> use >> >> UDP >> >> >> as >> >> >> >> > an Internet transport must employ mechanisms to prevent >> >> >> congestion >> >> >> >> > collapse and to establish some degree of fairness with >> >> concurrent >> >> >> >> > traffic. They may also need to implement additional >> >> mechanisms, >> >> >> >> > depending on how they use UDP. >> >> >> >> > >> >> >> >> > This document provides guidelines on the use of UDP for the >> >> >> >> designers >> >> >> >> > of applications, tunnels and other protocols that use UDP. >> >> >> >> > Congestion control guidelines are a primary focus, but the >> >> >> document >> >> >> >> > also provides guidance on other topics, including message >> >> sizes, >> >> >> >> > reliability, checksums, and middlebox traversal. >> >> >> >> > >> >> >> >> > If published as an RFC, this document will obsolete >> RFC5405. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > Please note that it may take a couple of minutes from the >> time >> >> of >> >> >> >> submission >> >> >> >> > until the htmlized version and diff are available at >> >> >> tools.ietf.org. >> >> >> >> > >> >> >> >> > The IETF Secretariat >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> > From nobody Mon Jun 16 13:46: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 C5A581A0218 for ; Mon, 16 Jun 2014 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 IhykPlv3wyCg for ; Mon, 16 Jun 2014 13:45:46 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1191A01EB for ; Mon, 16 Jun 2014 13:45:45 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so4753373wib.1 for ; Mon, 16 Jun 2014 13:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DIZBHyYuPXoZlCNmyFH8qDVqjCYAEWJx6nbtNfoGyYI=; b=zMT0G4Ix2795vTr4fid1ndx/HrzVxzTJ3J3RnnQlJusANqbtmHF7CBY3sRuHEApZ3e cvzJaWO+CFUlwyhmJmv7xW09tgkCjiiMmdj+tONbhE8uYVpBd5HWz/5+Y42k0VqaB6uG ydl43B6NQru58Avo3353tyr8VcBfMurxF+EncBqrDw6nB4cfv1XqI9tBeI5eRbHm6zoC rjZywLeWRjQwnRxDFoh/h4TkC3KwQQxQutdAOF4GkcW8QcPDUzMgf4YmO554hQEjP814 TaDNLdTM+gRAvPizFHLpfUJYLXgeHsAHVHdB8HpJfxStuDblly8+jaGN71p+ca32aEqg uuKQ== MIME-Version: 1.0 X-Received: by 10.194.76.212 with SMTP id m20mr31594889wjw.30.1402951544340; Mon, 16 Jun 2014 13:45:44 -0700 (PDT) Received: by 10.180.21.211 with HTTP; Mon, 16 Jun 2014 13:45:44 -0700 (PDT) In-Reply-To: <193fa185d1c175afed42ac03e966a0b0.squirrel@www.erg.abdn.ac.uk> References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> <193fa185d1c175afed42ac03e966a0b0.squirrel@www.erg.abdn.ac.uk> Date: Mon, 16 Jun 2014 13:45:44 -0700 Message-ID: From: Greg Shepherd To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=047d7bfd078270081404fbfa1c4d Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/1H7qIAZP6WUhlRmVgTWqSPSeszo Cc: "" Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:45:54 -0000 --047d7bfd078270081404fbfa1c4d Content-Type: text/plain; charset=UTF-8 On Mon, Jun 16, 2014 at 1:31 PM, wrote: > So, basically, ALC doesn't mention RTT, but NORM does. Both of these > react on larger time scales than TCP would have reacted to the same > congestion event. So if we remove RTT is this OK: > > Section 4.1: > Congestion control mechanisms for multicast may operate on longer > timescales than for unicast (especially where group members have > widely different path delays). Appropriate methods are particularly > important for any multicast session were all or part of the multicast > distribution tree spans an access network (e.g., a home gateway). > Again, this is topology dependent. It may also operate on much shorter timescales. Greg > Gorry > > > On Mon, Jun 16, 2014 at 1:12 PM, wrote: > > > >> In-line > >> > >> > Inline: > >> > > >> > On Mon, Jun 16, 2014 at 12:34 PM, wrote: > >> > > >> >> See-in-line > >> >> > On Mon, Jun 16, 2014 at 11:33 AM, wrote: > >> >> > > >> >> >> I'll respond on the RTT query - since I wrote that section. > >> >> >> > >> >> >> I'm, not sure what you are saying, are you saying there are > >> methods > >> >> that > >> >> >> determine how to respond to congestion that take less than one > >> RTT, > >> >> or > >> >> >> simply the group RTT isn't an issue - maybe I'd see better with an > >> >> >> example? > >> >> > > >> >> > > >> >> > Right, the whole concept of RTT is irrelevant here since there is > >> no > >> >> > message round trip from receiver to source and back. The CC > >> >> determination > >> >> > (channel selection/combination) is determined by the application > >> >> without > >> >> > upstream signaling at all. That was the point of the last sentence > >> in > >> >> the > >> >> > previous paragraph which came from section 2.1 of my > >> >> > draft draft-shepherd-multicast-udp-guidelines-01.txt > >> >> > > >> >> I had some doubt about that part: Let me see if I can explain what I > >> am > >> >> thinking: > >> >> > >> >> - For example, using ALC, I'd have expected loss due to congestion at > >> a > >> >> bottleneck to result in each receiver downstream of the bottleneck > >> in > >> >> reducing the group membership for the higher-rate streams, but the > >> >> required rate reduction takes a little while to propagate up the > >> (PIM) > >> >> multicast distribution tree, and the source only ceases when there > >> are > >> >> no > >> >> further subscriptions (or timeout). > >> >> > >> > > >> > We're already gone off track here; RTT is just a measure of time. It > >> > doesn't itself directly refer to any form of CC. Join latency is not > >> RTT. > >> > WEBRC coined the term MRTT in an attempt to tie join-latency to the > >> > concept > >> > of RTT as it applies to CC. > >> > > >> I don't agree - even though there may be no "RTT timer", the largest > >> round > >> trip time of any receiver in the ALC group is still the parameter that > >> controls the responsiveness of the CC mechanism. > > > > > > Almost right.. It's not any round trip time. It's join/leave latency. I'm > > not arguing the mechanism, I'm arguing the term. We need to be clear - > > there is not control RTT like TCP here. > > > > > >> > > >> >> Whatever, ALC would take at least a RTT to the furthest receiver > >> (with > >> >> loss) that has subscribed to the group, before the source has a > >> chance > >> >> to > >> >> reduce the load on the bottleneck. > >> >> > >> > > >> > I don't believe ALC sources change rates at all. There is a rate/group > >> > profile which the receiver application side selects. > >> > > >> I should have been clearer, the rate at which the source injects traffic > >> into the congested bottleneck queue. The rate at which the ALC source > >> feeds this queue varies as the subscription to higher-rate groups > >> subside. > > > > > > Sure, but this is a topology dependency and no application will be able > to > > respond to where congestion occurs, only if/when they see congestion > > directly. Just like TCP - it has no clue where congestion occurs. It just > > reacts to local detection. > > > > Greg > > > > > >> > > >> >> I know you could also immediately react to loss (aka NORM), but then > >> >> that > >> >> would prevent heterogenous operation where one part of the group can > >> >> receive faster than others. This reaction is more conservative from a > >> CC > >> >> viewpoint > >> > > >> > > >> > ..which goes into the description of various CC mechanisms and departs > >> > from > >> > any applicability of RTT. > >> > > >> > Greg > >> > > >> > >> > >> Gorry > >> > > >> >> > >> >> Gorry > >> >> > >> >> > Greg > >> >> > > >> >> > > >> >> > > >> >> >> > >> >> >> Gorry > >> >> >> > >> >> >> > >> >> >> > Thanks Lars. Much of this text is taken directly from my > >> previous > >> >> >> > draft, draft-shepherd-multicast-udp. Can you please add me to > >> the > >> >> >> authors > >> >> >> > list of this draft? > >> >> >> > > >> >> >> > Content notes: > >> >> >> > > >> >> >> > Section 4.1: > >> >> >> > > >> >> >> > Congestion control mechanisms for multicast may operate on > >> longer > >> >> >> > timescales than for unicast (e.g., due to the higher group > >> RTT > >> >> of a > >> >> >> > heterogeneous group); appropriate methods are particularly > >> for > >> >> any > >> >> >> > multicast session were all or part of the multicast > >> distribution > >> >> >> tree > >> >> >> > spans an access network (e.g., a home gateway). > >> >> >> > > >> >> >> > > >> >> >> > The above isn't relevant for application based CC mechanism. In > >> >> fact, > >> >> >> an > >> >> >> > application-based mechanism may often operate faster than any > >> RTT > >> >> >> > dependent > >> >> >> > mechanism. I think we should either remove this paragraph > >> entirely > >> >> or > >> >> >> > restructure it to make the point that application based CC > >> operates > >> >> >> > without > >> >> >> > dependency on RTT. > >> >> >> > > >> >> >> > Greg > >> >> >> > > >> >> >> > > >> >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars > >> >> wrote: > >> >> >> > > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >> Gorry and me have started to put together an update to RFC5405 > >> in > >> >> >> light > >> >> >> >> of > >> >> >> >> the recent discussions. Comments welcome. > >> >> >> >> > >> >> >> >> Lars > >> >> >> >> > >> >> >> >> > >> >> >> >> Begin forwarded message: > >> >> >> >> > >> >> >> >> > From: > >> >> >> >> > Subject: New Version Notification for > >> >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2 > >> >> >> >> > To: Lars Eggert , Godred Fairhurst < > >> >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst , > >> >> Lars > >> >> >> >> Eggert > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> >> > has been successfully submitted by Lars Eggert and posted to > >> the > >> >> >> >> > IETF repository. > >> >> >> >> > > >> >> >> >> > Name: draft-eggert-tsvwg-rfc5405bis > >> >> >> >> > Revision: 00 > >> >> >> >> > Title: UDP Usage Guidelines > >> >> >> >> > Document date: 2014-06-14 > >> >> >> >> > Group: Individual Submission > >> >> >> >> > Pages: 36 > >> >> >> >> > URL: > >> >> >> >> > >> >> >> > >> >> > >> > http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> >> > Status: > >> >> >> >> > https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ > >> >> >> >> > Htmlized: > >> >> >> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > Abstract: > >> >> >> >> > The User Datagram Protocol (UDP) provides a minimal > >> >> >> message-passing > >> >> >> >> > transport that has no inherent congestion control > >> mechanisms. > >> >> >> >> > Because congestion control is critical to the stable > >> operation > >> >> of > >> >> >> >> the > >> >> >> >> > Internet, applications and other protocols that choose to > >> use > >> >> UDP > >> >> >> as > >> >> >> >> > an Internet transport must employ mechanisms to prevent > >> >> >> congestion > >> >> >> >> > collapse and to establish some degree of fairness with > >> >> concurrent > >> >> >> >> > traffic. They may also need to implement additional > >> >> mechanisms, > >> >> >> >> > depending on how they use UDP. > >> >> >> >> > > >> >> >> >> > This document provides guidelines on the use of UDP for the > >> >> >> >> designers > >> >> >> >> > of applications, tunnels and other protocols that use UDP. > >> >> >> >> > Congestion control guidelines are a primary focus, but the > >> >> >> document > >> >> >> >> > also provides guidance on other topics, including message > >> >> sizes, > >> >> >> >> > reliability, checksums, and middlebox traversal. > >> >> >> >> > > >> >> >> >> > If published as an RFC, this document will obsolete > >> RFC5405. > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > Please note that it may take a couple of minutes from the > >> time > >> >> of > >> >> >> >> submission > >> >> >> >> > until the htmlized version and diff are available at > >> >> >> tools.ietf.org. > >> >> >> >> > > >> >> >> >> > The IETF Secretariat > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> >> > >> > > >> > >> > >> > > > > > --047d7bfd078270081404fbfa1c4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 16, 2014 at 1:31 PM, <gorry@erg.abdn.ac.u= k> wrote:
So, basically, =C2=A0ALC doesn't mention RTT, but NORM does. Both of th= ese
react on larger time scales than TCP would have reacted to the same
congestion event. So if we remove RTT is this OK:

Section 4.1:
Congestion control mechanisms for multicast may operate on longer
timescales than for unicast (especially where group members have
widely different path delays). Appropriate methods are particularly
important for any multicast session were all or part of the multicast
distribution tree spans an access network (e.g., a= home gateway).

Again, this is to= pology dependent. It may also operate on much shorter timescales.

Greg
=C2=A0
Gorry

> On Mon, Jun 16, 2014 at 1:12 PM, <gorry@erg.abdn.ac.uk> wrote:
>
>> In-line
>>
>> > Inline:
>> >
>> > On Mon, Jun 16, 2014 at 12:34 PM, <gorry@erg.abdn.ac.uk> wrote:
>> >
>> >> See-in-line
>> >> > On Mon, Jun 16, 2014 at 11:33 AM, <gorry@erg.abdn.ac.uk> wrote:
>> >> >
>> >> >> I'll respond on the RTT query - since I wrot= e that section.
>> >> >>
>> >> >> I'm, not sure what you are saying, are you s= aying there are
>> methods
>> >> that
>> >> >> determine how to respond to congestion that take= less than one
>> RTT,
>> >> or
>> >> >> simply the group RTT isn't an issue - maybe = I'd see better with an
>> >> >> example?
>> >> >
>> >> >
>> >> > Right, the whole concept of RTT is irrelevant here s= ince there is
>> no
>> >> > message round trip from receiver to source and back.= The CC
>> >> determination
>> >> > (channel selection/combination) is determined by the= application
>> >> without
>> >> > upstream signaling at all. That was the point of the= last sentence
>> in
>> >> the
>> >> > previous paragraph which came from section 2.1 of my=
>> >> > draft draft-shepherd-multicast-udp-guidelines-01.txt=
>> >> >
>> >> I had some doubt about that part: Let me see if I can exp= lain what I
>> am
>> >> thinking:
>> >>
>> >> - For example, using ALC, I'd have expected loss due = to congestion at
>> a
>> >> bottleneck to result in =C2=A0each receiver downstream of= the bottleneck
>> in
>> >> reducing the group membership for the higher-rate streams= , but the
>> >> required rate reduction takes a little while to propagate= up the
>> (PIM)
>> >> multicast distribution tree, and the source only ceases w= hen there
>> are
>> >> no
>> >> further subscriptions (or timeout).
>> >>
>> >
>> > We're already gone off track here; RTT is just a measure = of time. It
>> > doesn't itself directly refer to any form of CC. Join lat= ency is not
>> RTT.
>> > WEBRC coined the term MRTT in an attempt to tie join-latency = to the
>> > concept
>> > of RTT as it applies to CC.
>> >
>> I don't agree - even though there may be no "RTT timer&qu= ot;, the largest
>> round
>> trip time of any receiver in the ALC group is still the parameter = that
>> controls the responsiveness of the CC mechanism.
>
>
> Almost right.. It's not any round trip time. It's join/leave l= atency. I'm
> not arguing the mechanism, I'm arguing the term. We need to be cle= ar -
> there is not control RTT like TCP here.
>
>
>> >
>> >> Whatever, ALC would take at least a RTT to the furthest r= eceiver
>> (with
>> >> loss) that has subscribed to the group, before the source= has a
>> chance
>> >> to
>> >> reduce the load on the bottleneck.
>> >>
>> >
>> > I don't believe ALC sources change rates at all. There is= a rate/group
>> > profile which the receiver application side selects.
>> >
>> I should have been clearer, the rate at which the source injects t= raffic
>> into the congested bottleneck queue. The rate at which the ALC sou= rce
>> feeds this queue varies as the subscription to higher-rate groups<= br> >> subside.
>
>
> Sure, but this is a topology dependency and no application will be abl= e to
> respond to where congestion occurs, only if/when they see congestion > directly. Just like TCP - it has no clue where congestion occurs. It j= ust
> reacts to local detection.
>
> Greg
>
>
>> >
>> >> I know you could also immediately react to loss (aka NORM= ), but then
>> >> that
>> >> would prevent heterogenous operation where one part of th= e group can
>> >> receive faster than others. This reaction is more conserv= ative from a
>> CC
>> >> viewpoint
>> >
>> >
>> > ..which goes into the description of various CC mechanisms an= d departs
>> > from
>> > any applicability of RTT.
>> >
>> > Greg
>> >
>>
>>
>> Gorry
>> >
>> >>
>> >> Gorry
>> >>
>> >> > Greg
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> Gorry
>> >> >>
>> >> >>
>> >> >> > Thanks Lars. Much of this text is taken dir= ectly from my
>> previous
>> >> >> > draft, draft-shepherd-multicast-udp. Can yo= u please add me to
>> the
>> >> >> authors
>> >> >> > list of this draft?
>> >> >> >
>> >> >> > Content notes:
>> >> >> >
>> >> >> > Section 4.1:
>> >> >> >
>> >> >> > Congestion control mechanisms for multicast= may operate on
>> longer
>> >> >> > =C2=A0 =C2=A0timescales than for unicast (e= .g., due to the higher group
>> RTT
>> >> of a
>> >> >> > =C2=A0 =C2=A0heterogeneous group); appropri= ate methods are particularly
>> for
>> >> any
>> >> >> > =C2=A0 =C2=A0multicast session were all or = part of the multicast
>> distribution
>> >> >> tree
>> >> >> > =C2=A0 =C2=A0spans an access network (e.g.,= a home gateway).
>> >> >> >
>> >> >> >
>> >> >> > The above isn't relevant for applicatio= n based CC mechanism. In
>> >> fact,
>> >> >> an
>> >> >> > application-based mechanism may often opera= te faster than any
>> RTT
>> >> >> > dependent
>> >> >> > mechanism. I think we should either remove = this paragraph
>> entirely
>> >> or
>> >> >> > restructure it to make the point that appli= cation based CC
>> operates
>> >> >> > without
>> >> >> > dependency on RTT.
>> >> >> >
>> >> >> > Greg
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, La= rs <lars@netapp.com>
>> >> wrote:
>> >> >> >
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> Gorry and me have started to put togeth= er an update to RFC5405
>> in
>> >> >> light
>> >> >> >> of
>> >> >> >> the recent discussions. Comments welcom= e.
>> >> >> >>
>> >> >> >> Lars
>> >> >> >>
>> >> >> >>
>> >> >> >> Begin forwarded message:
>> >> >> >>
>> >> >> >> > From: <internet-drafts@ietf.org>
>> >> >> >> > Subject: New Version Notification = for
>> >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> > Date: June 14, 2014 at 12:14:42 GM= T+2
>> >> >> >> > To: Lars Eggert <lars@netapp.com>, Godred Fairhurst <
>> >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>,
>> >> Lars
>> >> >> >> Eggert <lars@netapp.com>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > A new version of I-D, draft-eggert= -tsvwg-rfc5405bis-00.txt
>> >> >> >> > has been successfully submitted by= Lars Eggert and posted to
>> the
>> >> >> >> > IETF repository.
>> >> >> >> >
>> >> >> >> > Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = draft-eggert-tsvwg-rfc5405bis
>> >> >> >> > Revision: =C2=A0 =C2=A0 00
>> >> >> >> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0UDP Usage Guidelines
>> >> >> >> > Document date: =C2=A0 =C2=A0 =C2= =A0 =C2=A02014-06-14
>> >> >> >> > Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>> >> >> >> > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A036
>> >> >> >> > URL:
>> >> >> >>
>> >> >>
>> >>
>> http://www.ietf.org/internet-drafts/dr= aft-eggert-tsvwg-rfc5405bis-00.txt
>> >> >> >> > Status:
>> >> >> >> https://datatracker.= ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/
>> >> >> >> > Htmlized:
>> >> >> >> http://tools.ietf.org/ht= ml/draft-eggert-tsvwg-rfc5405bis-00
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Abstract:
>> >> >> >> > =C2=A0 The User Datagram Protocol = (UDP) provides a minimal
>> >> >> message-passing
>> >> >> >> > =C2=A0 transport that has no inher= ent congestion control
>> mechanisms.
>> >> >> >> > =C2=A0 Because congestion control = is critical to the stable
>> operation
>> >> of
>> >> >> >> the
>> >> >> >> > =C2=A0 Internet, applications and = other protocols that choose to
>> use
>> >> UDP
>> >> >> as
>> >> >> >> > =C2=A0 an Internet transport must = employ mechanisms to prevent
>> >> >> congestion
>> >> >> >> > =C2=A0 collapse and to establish s= ome degree of fairness with
>> >> concurrent
>> >> >> >> > =C2=A0 traffic. =C2=A0They may als= o need to implement additional
>> >> mechanisms,
>> >> >> >> > =C2=A0 depending on how they use U= DP.
>> >> >> >> >
>> >> >> >> > =C2=A0 This document provides guid= elines on the use of UDP for the
>> >> >> >> designers
>> >> >> >> > =C2=A0 of applications, tunnels an= d other protocols that use UDP.
>> >> >> >> > =C2=A0 Congestion control guidelin= es are a primary focus, but the
>> >> >> document
>> >> >> >> > =C2=A0 also provides guidance on o= ther topics, including message
>> >> sizes,
>> >> >> >> > =C2=A0 reliability, checksums, and= middlebox traversal.
>> >> >> >> >
>> >> >> >> > =C2=A0 If published as an RFC, thi= s document will obsolete
>> RFC5405.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Please note that it may take a cou= ple of minutes from the
>> time
>> >> of
>> >> >> >> submission
>> >> >> >> > until the htmlized version and dif= f are available at
>> >> >> tools.ietf.org.
>> >> >> >> >
>> >> >> >> > The IETF Secretariat
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



--047d7bfd078270081404fbfa1c4d-- From nobody Mon Jun 16 23:46: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 51F9E1A0290 for ; Mon, 16 Jun 2014 23:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 KI3jcw6oiXcy for ; Mon, 16 Jun 2014 23:46:31 -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 F40EB1A0289 for ; Mon, 16 Jun 2014 23:46:30 -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 D97872B40E1; Tue, 17 Jun 2014 07:46:28 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 17 Jun 2014 07:46:29 +0100 Message-ID: In-Reply-To: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> <193fa185d1c175afed42ac03e966a0b0.squirrel@www.erg.abdn.ac.uk> Date: Tue, 17 Jun 2014 07:46:29 +0100 From: gorry@erg.abdn.ac.uk To: gjshep@gmail.com 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/_FxrsLqUsZODhu2wuvDBcSCGhwc Cc: Gorry Fairhurst , tsvwg@ietf.org Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.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: Tue, 17 Jun 2014 06:46:34 -0000 > On Mon, Jun 16, 2014 at 1:31 PM, wrote: > >> So, basically, ALC doesn't mention RTT, but NORM does. Both of these >> react on larger time scales than TCP would have reacted to the same >> congestion event. So if we remove RTT is this OK: >> >> Section 4.1: >> Congestion control mechanisms for multicast may operate on longer >> timescales than for unicast (especially where group members have >> widely different path delays). Appropriate methods are particularly >> important for any multicast session were all or part of the multicast >> distribution tree spans an access network (e.g., a home gateway). >> > > Again, this is topology dependent. It may also operate on much shorter > timescales. > > Greg > Maybe layered congestion control is a good example, where congestion at the edge of the tree results in a response as soon as multicast router before the congestion bottleneck prunes the traffic - but I'm not sure this implies the router immediately stops forwarding? Maybe we can agree on: Section 4.1: Congestion control mechanisms for multicast may operate on different timescales than for unicast depending on the topology, CC method and point of congestion. Appropriate methods are particularly important for any multicast session were all or part of the multicast distribution tree spans an access network (e.g., a home gateway). Gorry > >> Gorry >> >> > On Mon, Jun 16, 2014 at 1:12 PM, wrote: >> > >> >> In-line >> >> >> >> > Inline: >> >> > >> >> > On Mon, Jun 16, 2014 at 12:34 PM, wrote: >> >> > >> >> >> See-in-line >> >> >> > On Mon, Jun 16, 2014 at 11:33 AM, wrote: >> >> >> > >> >> >> >> I'll respond on the RTT query - since I wrote that section. >> >> >> >> >> >> >> >> I'm, not sure what you are saying, are you saying there are >> >> methods >> >> >> that >> >> >> >> determine how to respond to congestion that take less than one >> >> RTT, >> >> >> or >> >> >> >> simply the group RTT isn't an issue - maybe I'd see better with >> an >> >> >> >> example? >> >> >> > >> >> >> > >> >> >> > Right, the whole concept of RTT is irrelevant here since there >> is >> >> no >> >> >> > message round trip from receiver to source and back. The CC >> >> >> determination >> >> >> > (channel selection/combination) is determined by the application >> >> >> without >> >> >> > upstream signaling at all. That was the point of the last >> sentence >> >> in >> >> >> the >> >> >> > previous paragraph which came from section 2.1 of my >> >> >> > draft draft-shepherd-multicast-udp-guidelines-01.txt >> >> >> > >> >> >> I had some doubt about that part: Let me see if I can explain what >> I >> >> am >> >> >> thinking: >> >> >> >> >> >> - For example, using ALC, I'd have expected loss due to congestion >> at >> >> a >> >> >> bottleneck to result in each receiver downstream of the >> bottleneck >> >> in >> >> >> reducing the group membership for the higher-rate streams, but the >> >> >> required rate reduction takes a little while to propagate up the >> >> (PIM) >> >> >> multicast distribution tree, and the source only ceases when there >> >> are >> >> >> no >> >> >> further subscriptions (or timeout). >> >> >> >> >> > >> >> > We're already gone off track here; RTT is just a measure of time. >> It >> >> > doesn't itself directly refer to any form of CC. Join latency is >> not >> >> RTT. >> >> > WEBRC coined the term MRTT in an attempt to tie join-latency to the >> >> > concept >> >> > of RTT as it applies to CC. >> >> > >> >> I don't agree - even though there may be no "RTT timer", the largest >> >> round >> >> trip time of any receiver in the ALC group is still the parameter >> that >> >> controls the responsiveness of the CC mechanism. >> > >> > >> > Almost right.. It's not any round trip time. It's join/leave latency. >> I'm >> > not arguing the mechanism, I'm arguing the term. We need to be clear - >> > there is not control RTT like TCP here. >> > >> > >> >> > >> >> >> Whatever, ALC would take at least a RTT to the furthest receiver >> >> (with >> >> >> loss) that has subscribed to the group, before the source has a >> >> chance >> >> >> to >> >> >> reduce the load on the bottleneck. >> >> >> >> >> > >> >> > I don't believe ALC sources change rates at all. There is a >> rate/group >> >> > profile which the receiver application side selects. >> >> > >> >> I should have been clearer, the rate at which the source injects >> traffic >> >> into the congested bottleneck queue. The rate at which the ALC source >> >> feeds this queue varies as the subscription to higher-rate groups >> >> subside. >> > >> > >> > Sure, but this is a topology dependency and no application will be >> able >> to >> > respond to where congestion occurs, only if/when they see congestion >> > directly. Just like TCP - it has no clue where congestion occurs. It >> just >> > reacts to local detection. >> > >> > Greg >> > >> > >> >> > >> >> >> I know you could also immediately react to loss (aka NORM), but >> then >> >> >> that >> >> >> would prevent heterogenous operation where one part of the group >> can >> >> >> receive faster than others. This reaction is more conservative >> from a >> >> CC >> >> >> viewpoint >> >> > >> >> > >> >> > ..which goes into the description of various CC mechanisms and >> departs >> >> > from >> >> > any applicability of RTT. >> >> > >> >> > Greg >> >> > >> >> >> >> >> >> Gorry >> >> > >> >> >> >> >> >> Gorry >> >> >> >> >> >> > Greg >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Gorry >> >> >> >> >> >> >> >> >> >> >> >> > Thanks Lars. Much of this text is taken directly from my >> >> previous >> >> >> >> > draft, draft-shepherd-multicast-udp. Can you please add me to >> >> the >> >> >> >> authors >> >> >> >> > list of this draft? >> >> >> >> > >> >> >> >> > Content notes: >> >> >> >> > >> >> >> >> > Section 4.1: >> >> >> >> > >> >> >> >> > Congestion control mechanisms for multicast may operate on >> >> longer >> >> >> >> > timescales than for unicast (e.g., due to the higher group >> >> RTT >> >> >> of a >> >> >> >> > heterogeneous group); appropriate methods are particularly >> >> for >> >> >> any >> >> >> >> > multicast session were all or part of the multicast >> >> distribution >> >> >> >> tree >> >> >> >> > spans an access network (e.g., a home gateway). >> >> >> >> > >> >> >> >> > >> >> >> >> > The above isn't relevant for application based CC mechanism. >> In >> >> >> fact, >> >> >> >> an >> >> >> >> > application-based mechanism may often operate faster than any >> >> RTT >> >> >> >> > dependent >> >> >> >> > mechanism. I think we should either remove this paragraph >> >> entirely >> >> >> or >> >> >> >> > restructure it to make the point that application based CC >> >> operates >> >> >> >> > without >> >> >> >> > dependency on RTT. >> >> >> >> > >> >> >> >> > Greg >> >> >> >> > >> >> >> >> > >> >> >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars >> >> >> >> wrote: >> >> >> >> > >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> Gorry and me have started to put together an update to >> RFC5405 >> >> in >> >> >> >> light >> >> >> >> >> of >> >> >> >> >> the recent discussions. Comments welcome. >> >> >> >> >> >> >> >> >> >> Lars >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> >> >> >> >> >> >> >> >> > From: >> >> >> >> >> > Subject: New Version Notification for >> >> >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2 >> >> >> >> >> > To: Lars Eggert , Godred Fairhurst < >> >> >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst >> , >> >> >> Lars >> >> >> >> >> Eggert >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> >> > has been successfully submitted by Lars Eggert and posted >> to >> >> the >> >> >> >> >> > IETF repository. >> >> >> >> >> > >> >> >> >> >> > Name: draft-eggert-tsvwg-rfc5405bis >> >> >> >> >> > Revision: 00 >> >> >> >> >> > Title: UDP Usage Guidelines >> >> >> >> >> > Document date: 2014-06-14 >> >> >> >> >> > Group: Individual Submission >> >> >> >> >> > Pages: 36 >> >> >> >> >> > URL: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt >> >> >> >> >> > Status: >> >> >> >> >> >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ >> >> >> >> >> > Htmlized: >> >> >> >> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > Abstract: >> >> >> >> >> > The User Datagram Protocol (UDP) provides a minimal >> >> >> >> message-passing >> >> >> >> >> > transport that has no inherent congestion control >> >> mechanisms. >> >> >> >> >> > Because congestion control is critical to the stable >> >> operation >> >> >> of >> >> >> >> >> the >> >> >> >> >> > Internet, applications and other protocols that choose >> to >> >> use >> >> >> UDP >> >> >> >> as >> >> >> >> >> > an Internet transport must employ mechanisms to prevent >> >> >> >> congestion >> >> >> >> >> > collapse and to establish some degree of fairness with >> >> >> concurrent >> >> >> >> >> > traffic. They may also need to implement additional >> >> >> mechanisms, >> >> >> >> >> > depending on how they use UDP. >> >> >> >> >> > >> >> >> >> >> > This document provides guidelines on the use of UDP for >> the >> >> >> >> >> designers >> >> >> >> >> > of applications, tunnels and other protocols that use >> UDP. >> >> >> >> >> > Congestion control guidelines are a primary focus, but >> the >> >> >> >> document >> >> >> >> >> > also provides guidance on other topics, including >> message >> >> >> sizes, >> >> >> >> >> > reliability, checksums, and middlebox traversal. >> >> >> >> >> > >> >> >> >> >> > If published as an RFC, this document will obsolete >> >> RFC5405. >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > Please note that it may take a couple of minutes from the >> >> time >> >> >> of >> >> >> >> >> submission >> >> >> >> >> > until the htmlized version and diff are available at >> >> >> >> tools.ietf.org. >> >> >> >> >> > >> >> >> >> >> > The IETF Secretariat >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> > From nobody Tue Jun 17 07:54:42 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 B42E01A0394 for ; Tue, 17 Jun 2014 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 uq-3IteU4xdQ for ; Tue, 17 Jun 2014 07:54:30 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c: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 A69351A0369 for ; Tue, 17 Jun 2014 07:54:29 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so6700526wes.9 for ; Tue, 17 Jun 2014 07:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TxytF8TIpIuaAqq+b2cF4eovFPQ3rvnP9xoP6AMY+8o=; b=wo1IO9GwztVGr57PKziHaVWcyswudwiCseRZsifJnb6PjMjxpRhSSH5rkujNzsAQ+g zYUUkvMuZJcfUba2Qwvb9Pq1yWtziBfwvOWhUTcJ1peZPwoOxNz6g5Covl3krNgwHjJV Mg65gUIfqPXR6uBjI5o8nOXnIEMVp6S/NQ+p86g/mc0FuQLoNZkTFb0bGPRT9BOOb8HJ XbaUJ4qT6wSsaj7lRkwRDQuJ+xElZerX79gBwebrQSYN6rx6/Hcszj2eU2snG4b2HX3a pSsOi8OOZxr6AQkvgRQ2isiFIVShnYmVAIZ9UYU8KEA5yylV3phSLCB6PkWV2oqhIT7w AMtQ== MIME-Version: 1.0 X-Received: by 10.180.206.132 with SMTP id lo4mr37460632wic.46.1403016868195; Tue, 17 Jun 2014 07:54:28 -0700 (PDT) Received: by 10.180.21.211 with HTTP; Tue, 17 Jun 2014 07:54:28 -0700 (PDT) In-Reply-To: References: <20140614101442.22657.40901.idtracker@ietfa.amsl.com> <193fa185d1c175afed42ac03e966a0b0.squirrel@www.erg.abdn.ac.uk> Date: Tue, 17 Jun 2014 07:54:28 -0700 Message-ID: From: Greg Shepherd To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=001a11c326aa0b27b704fc0952d5 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/lshrZE2DYyCg9vGKMIkzeIBHI20 Cc: "" Subject: Re: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 14:54:35 -0000 --001a11c326aa0b27b704fc0952d5 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 16, 2014 at 11:46 PM, wrote: > > On Mon, Jun 16, 2014 at 1:31 PM, wrote: > > > >> So, basically, ALC doesn't mention RTT, but NORM does. Both of these > >> react on larger time scales than TCP would have reacted to the same > >> congestion event. So if we remove RTT is this OK: > >> > >> Section 4.1: > >> Congestion control mechanisms for multicast may operate on longer > >> timescales than for unicast (especially where group members have > >> widely different path delays). Appropriate methods are particularly > >> important for any multicast session were all or part of the multicast > >> distribution tree spans an access network (e.g., a home gateway). > >> > > > > Again, this is topology dependent. It may also operate on much shorter > > timescales. > > > > Greg > > > Maybe layered congestion control is a good example, where congestion at > the edge of the tree results in a response as soon as multicast router > before the congestion bottleneck prunes the traffic - but I'm not sure > this implies the router immediately stops forwarding? > If there is only one receiver on that branch, the router should stop forwarding packets on that branch immediately upon receiving a IGMP leave message. If not, your router is broken. The time between the sending of the leave message and the pruning of the branch is the leave latency. > Maybe we can agree on: > > Section 4.1: > Congestion control mechanisms for multicast may operate on different > timescales than for unicast depending on the topology, CC method and point > of > congestion. Appropriate methods are particularly important for any > multicast session were all or part of the multicast distribution tree > spans an access network (e.g., a home gateway). > Looks good, thanks! Greg > Gorry > > > > >> Gorry > >> > >> > On Mon, Jun 16, 2014 at 1:12 PM, wrote: > >> > > >> >> In-line > >> >> > >> >> > Inline: > >> >> > > >> >> > On Mon, Jun 16, 2014 at 12:34 PM, wrote: > >> >> > > >> >> >> See-in-line > >> >> >> > On Mon, Jun 16, 2014 at 11:33 AM, wrote: > >> >> >> > > >> >> >> >> I'll respond on the RTT query - since I wrote that section. > >> >> >> >> > >> >> >> >> I'm, not sure what you are saying, are you saying there are > >> >> methods > >> >> >> that > >> >> >> >> determine how to respond to congestion that take less than one > >> >> RTT, > >> >> >> or > >> >> >> >> simply the group RTT isn't an issue - maybe I'd see better with > >> an > >> >> >> >> example? > >> >> >> > > >> >> >> > > >> >> >> > Right, the whole concept of RTT is irrelevant here since there > >> is > >> >> no > >> >> >> > message round trip from receiver to source and back. The CC > >> >> >> determination > >> >> >> > (channel selection/combination) is determined by the application > >> >> >> without > >> >> >> > upstream signaling at all. That was the point of the last > >> sentence > >> >> in > >> >> >> the > >> >> >> > previous paragraph which came from section 2.1 of my > >> >> >> > draft draft-shepherd-multicast-udp-guidelines-01.txt > >> >> >> > > >> >> >> I had some doubt about that part: Let me see if I can explain what > >> I > >> >> am > >> >> >> thinking: > >> >> >> > >> >> >> - For example, using ALC, I'd have expected loss due to congestion > >> at > >> >> a > >> >> >> bottleneck to result in each receiver downstream of the > >> bottleneck > >> >> in > >> >> >> reducing the group membership for the higher-rate streams, but the > >> >> >> required rate reduction takes a little while to propagate up the > >> >> (PIM) > >> >> >> multicast distribution tree, and the source only ceases when there > >> >> are > >> >> >> no > >> >> >> further subscriptions (or timeout). > >> >> >> > >> >> > > >> >> > We're already gone off track here; RTT is just a measure of time. > >> It > >> >> > doesn't itself directly refer to any form of CC. Join latency is > >> not > >> >> RTT. > >> >> > WEBRC coined the term MRTT in an attempt to tie join-latency to the > >> >> > concept > >> >> > of RTT as it applies to CC. > >> >> > > >> >> I don't agree - even though there may be no "RTT timer", the largest > >> >> round > >> >> trip time of any receiver in the ALC group is still the parameter > >> that > >> >> controls the responsiveness of the CC mechanism. > >> > > >> > > >> > Almost right.. It's not any round trip time. It's join/leave latency. > >> I'm > >> > not arguing the mechanism, I'm arguing the term. We need to be clear - > >> > there is not control RTT like TCP here. > >> > > >> > > >> >> > > >> >> >> Whatever, ALC would take at least a RTT to the furthest receiver > >> >> (with > >> >> >> loss) that has subscribed to the group, before the source has a > >> >> chance > >> >> >> to > >> >> >> reduce the load on the bottleneck. > >> >> >> > >> >> > > >> >> > I don't believe ALC sources change rates at all. There is a > >> rate/group > >> >> > profile which the receiver application side selects. > >> >> > > >> >> I should have been clearer, the rate at which the source injects > >> traffic > >> >> into the congested bottleneck queue. The rate at which the ALC source > >> >> feeds this queue varies as the subscription to higher-rate groups > >> >> subside. > >> > > >> > > >> > Sure, but this is a topology dependency and no application will be > >> able > >> to > >> > respond to where congestion occurs, only if/when they see congestion > >> > directly. Just like TCP - it has no clue where congestion occurs. It > >> just > >> > reacts to local detection. > >> > > >> > Greg > >> > > >> > > >> >> > > >> >> >> I know you could also immediately react to loss (aka NORM), but > >> then > >> >> >> that > >> >> >> would prevent heterogenous operation where one part of the group > >> can > >> >> >> receive faster than others. This reaction is more conservative > >> from a > >> >> CC > >> >> >> viewpoint > >> >> > > >> >> > > >> >> > ..which goes into the description of various CC mechanisms and > >> departs > >> >> > from > >> >> > any applicability of RTT. > >> >> > > >> >> > Greg > >> >> > > >> >> > >> >> > >> >> Gorry > >> >> > > >> >> >> > >> >> >> Gorry > >> >> >> > >> >> >> > Greg > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >> > >> >> >> >> Gorry > >> >> >> >> > >> >> >> >> > >> >> >> >> > Thanks Lars. Much of this text is taken directly from my > >> >> previous > >> >> >> >> > draft, draft-shepherd-multicast-udp. Can you please add me to > >> >> the > >> >> >> >> authors > >> >> >> >> > list of this draft? > >> >> >> >> > > >> >> >> >> > Content notes: > >> >> >> >> > > >> >> >> >> > Section 4.1: > >> >> >> >> > > >> >> >> >> > Congestion control mechanisms for multicast may operate on > >> >> longer > >> >> >> >> > timescales than for unicast (e.g., due to the higher group > >> >> RTT > >> >> >> of a > >> >> >> >> > heterogeneous group); appropriate methods are particularly > >> >> for > >> >> >> any > >> >> >> >> > multicast session were all or part of the multicast > >> >> distribution > >> >> >> >> tree > >> >> >> >> > spans an access network (e.g., a home gateway). > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > The above isn't relevant for application based CC mechanism. > >> In > >> >> >> fact, > >> >> >> >> an > >> >> >> >> > application-based mechanism may often operate faster than any > >> >> RTT > >> >> >> >> > dependent > >> >> >> >> > mechanism. I think we should either remove this paragraph > >> >> entirely > >> >> >> or > >> >> >> >> > restructure it to make the point that application based CC > >> >> operates > >> >> >> >> > without > >> >> >> >> > dependency on RTT. > >> >> >> >> > > >> >> >> >> > Greg > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars > >> > >> >> >> wrote: > >> >> >> >> > > >> >> >> >> >> Hi, > >> >> >> >> >> > >> >> >> >> >> Gorry and me have started to put together an update to > >> RFC5405 > >> >> in > >> >> >> >> light > >> >> >> >> >> of > >> >> >> >> >> the recent discussions. Comments welcome. > >> >> >> >> >> > >> >> >> >> >> Lars > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Begin forwarded message: > >> >> >> >> >> > >> >> >> >> >> > From: > >> >> >> >> >> > Subject: New Version Notification for > >> >> >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2 > >> >> >> >> >> > To: Lars Eggert , Godred Fairhurst < > >> >> >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst > >> , > >> >> >> Lars > >> >> >> >> >> Eggert > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> >> >> > has been successfully submitted by Lars Eggert and posted > >> to > >> >> the > >> >> >> >> >> > IETF repository. > >> >> >> >> >> > > >> >> >> >> >> > Name: draft-eggert-tsvwg-rfc5405bis > >> >> >> >> >> > Revision: 00 > >> >> >> >> >> > Title: UDP Usage Guidelines > >> >> >> >> >> > Document date: 2014-06-14 > >> >> >> >> >> > Group: Individual Submission > >> >> >> >> >> > Pages: 36 > >> >> >> >> >> > URL: > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt > >> >> >> >> >> > Status: > >> >> >> >> >> > >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/ > >> >> >> >> >> > Htmlized: > >> >> >> >> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00 > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > Abstract: > >> >> >> >> >> > The User Datagram Protocol (UDP) provides a minimal > >> >> >> >> message-passing > >> >> >> >> >> > transport that has no inherent congestion control > >> >> mechanisms. > >> >> >> >> >> > Because congestion control is critical to the stable > >> >> operation > >> >> >> of > >> >> >> >> >> the > >> >> >> >> >> > Internet, applications and other protocols that choose > >> to > >> >> use > >> >> >> UDP > >> >> >> >> as > >> >> >> >> >> > an Internet transport must employ mechanisms to prevent > >> >> >> >> congestion > >> >> >> >> >> > collapse and to establish some degree of fairness with > >> >> >> concurrent > >> >> >> >> >> > traffic. They may also need to implement additional > >> >> >> mechanisms, > >> >> >> >> >> > depending on how they use UDP. > >> >> >> >> >> > > >> >> >> >> >> > This document provides guidelines on the use of UDP for > >> the > >> >> >> >> >> designers > >> >> >> >> >> > of applications, tunnels and other protocols that use > >> UDP. > >> >> >> >> >> > Congestion control guidelines are a primary focus, but > >> the > >> >> >> >> document > >> >> >> >> >> > also provides guidance on other topics, including > >> message > >> >> >> sizes, > >> >> >> >> >> > reliability, checksums, and middlebox traversal. > >> >> >> >> >> > > >> >> >> >> >> > If published as an RFC, this document will obsolete > >> >> RFC5405. > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > Please note that it may take a couple of minutes from the > >> >> time > >> >> >> of > >> >> >> >> >> submission > >> >> >> >> >> > until the htmlized version and diff are available at > >> >> >> >> tools.ietf.org. > >> >> >> >> >> > > >> >> >> >> >> > The IETF Secretariat > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> >> > >> > > >> > >> > >> > > > > > --001a11c326aa0b27b704fc0952d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 16, 2014 at 11:46 PM, <<= a href=3D"mailto:gorry@erg.abdn.ac.uk" target=3D"_blank">gorry@erg.abdn.ac.= uk> wrote:
> On Mon, Jun 16, 2014 at 1:31 PM, <gorry@erg.abdn.ac.uk> wrote:
>
>> So, basically, =C2=A0ALC doesn't mention RTT, but NORM does. B= oth of these
>> react on larger time scales than TCP would have reacted to the sam= e
>> congestion event. So if we remove RTT is this OK:
>>
>> Section 4.1:
>> Congestion control mechanisms for multicast may operate on longer<= br> >> timescales than for unicast (especially where group members have >> widely different path delays). Appropriate methods are particularl= y
>> important for any multicast session were all or part of the multic= ast
>> distribution tree spans an access network (e.g., a home gateway).<= br> >>
>
> Again, this is topology dependent. It may also operate on much shorter=
> timescales.
>
> Greg
>
Maybe layered congestion control is a good example, where congestion = at
the edge of the tree results in a response as soon as multicast router
before the congestion bottleneck prunes the traffic - but I'm not sure<= br> this implies the router immediately stops forwarding?
=
If there is only one receiver on that branch, the router sho= uld stop forwarding packets on that branch immediately upon receiving a IGM= P leave message. If not, your router is broken. The time between the sendin= g of the leave message and the pruning of the branch is the leave latency.<= /div>
=C2=A0
Maybe we can agree on:

Section 4.1:
Congestion control mechanisms for multicast may operate on different
timescales than for unicast depending on the topology, CC method and point = of
congestion. =C2=A0Appropriate methods are particularly important for any
multicast session were all or part of the multicas= t distribution tree
spans an access network (e.g., a home gateway).
=
Looks good, thanks!

Greg
= =C2=A0
Gorry

>
>> Gorry
>>
>> > On Mon, Jun 16, 2014 at 1:12 PM, <gorry@erg.abdn.ac.uk> wrote:
>> >
>> >> In-line
>> >>
>> >> > Inline:
>> >> >
>> >> > On Mon, Jun 16, 2014 at 12:34 PM, <gorry@erg.abdn.ac.uk> wrote:
>> >> >
>> >> >> See-in-line
>> >> >> > On Mon, Jun 16, 2014 at 11:33 AM, <gorry@erg.abdn.ac.uk> wrote:
>> >> >> >
>> >> >> >> I'll respond on the RTT query - sin= ce I wrote that section.
>> >> >> >>
>> >> >> >> I'm, not sure what you are saying, = are you saying there are
>> >> methods
>> >> >> that
>> >> >> >> determine how to respond to congestion = that take less than one
>> >> RTT,
>> >> >> or
>> >> >> >> simply the group RTT isn't an issue= - maybe I'd see better with
>> an
>> >> >> >> example?
>> >> >> >
>> >> >> >
>> >> >> > Right, the whole concept of RTT is irreleva= nt here since there
>> is
>> >> no
>> >> >> > message round trip from receiver to source = and back. The CC
>> >> >> determination
>> >> >> > (channel selection/combination) is determin= ed by the application
>> >> >> without
>> >> >> > upstream signaling at all. That was the poi= nt of the last
>> sentence
>> >> in
>> >> >> the
>> >> >> > previous paragraph which came from section = 2.1 of my
>> >> >> > draft draft-shepherd-multicast-udp-guidelin= es-01.txt
>> >> >> >
>> >> >> I had some doubt about that part: Let me see if = I can explain what
>> I
>> >> am
>> >> >> thinking:
>> >> >>
>> >> >> - For example, using ALC, I'd have expected = loss due to congestion
>> at
>> >> a
>> >> >> bottleneck to result in =C2=A0each receiver down= stream of the
>> bottleneck
>> >> in
>> >> >> reducing the group membership for the higher-rat= e streams, but the
>> >> >> required rate reduction takes a little while to = propagate up the
>> >> (PIM)
>> >> >> multicast distribution tree, and the source only= ceases when there
>> >> are
>> >> >> no
>> >> >> further subscriptions (or timeout).
>> >> >>
>> >> >
>> >> > We're already gone off track here; RTT is just a= measure of time.
>> It
>> >> > doesn't itself directly refer to any form of CC.= Join latency is
>> not
>> >> RTT.
>> >> > WEBRC coined the term MRTT in an attempt to tie join= -latency to the
>> >> > concept
>> >> > of RTT as it applies to CC.
>> >> >
>> >> I don't agree - even though there may be no "RTT= timer", the largest
>> >> round
>> >> trip time of any receiver in the ALC group is still the p= arameter
>> that
>> >> controls the responsiveness of the CC mechanism.
>> >
>> >
>> > Almost right.. It's not any round trip time. It's joi= n/leave latency.
>> I'm
>> > not arguing the mechanism, I'm arguing the term. We need = to be clear -
>> > there is not control RTT like TCP here.
>> >
>> >
>> >> >
>> >> >> Whatever, ALC would take at least a RTT to the f= urthest receiver
>> >> (with
>> >> >> loss) that has subscribed to the group, before t= he source has a
>> >> chance
>> >> >> to
>> >> >> reduce the load on the bottleneck.
>> >> >>
>> >> >
>> >> > I don't believe ALC sources change rates at all.= There is a
>> rate/group
>> >> > profile which the receiver application side selects.=
>> >> >
>> >> I should have been clearer, the rate at which the source = injects
>> traffic
>> >> into the congested bottleneck queue. The rate at which th= e ALC source
>> >> feeds this queue varies as the subscription to higher-rat= e groups
>> >> subside.
>> >
>> >
>> > Sure, but this is a topology dependency and no application wi= ll be
>> able
>> to
>> > respond to where congestion occurs, only if/when they see con= gestion
>> > directly. Just like TCP - it has no clue where congestion occ= urs. It
>> just
>> > reacts to local detection.
>> >
>> > Greg
>> >
>> >
>> >> >
>> >> >> I know you could also immediately react to loss = (aka NORM), but
>> then
>> >> >> that
>> >> >> would prevent heterogenous operation where one p= art of the group
>> can
>> >> >> receive faster than others. This reaction is mor= e conservative
>> from a
>> >> CC
>> >> >> viewpoint
>> >> >
>> >> >
>> >> > ..which goes into the description of various CC mech= anisms and
>> departs
>> >> > from
>> >> > any applicability of RTT.
>> >> >
>> >> > Greg
>> >> >
>> >>
>> >>
>> >> Gorry
>> >> >
>> >> >>
>> >> >> Gorry
>> >> >>
>> >> >> > Greg
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> Gorry
>> >> >> >>
>> >> >> >>
>> >> >> >> > Thanks Lars. Much of this text is = taken directly from my
>> >> previous
>> >> >> >> > draft, draft-shepherd-multicast-ud= p. Can you please add me to
>> >> the
>> >> >> >> authors
>> >> >> >> > list of this draft?
>> >> >> >> >
>> >> >> >> > Content notes:
>> >> >> >> >
>> >> >> >> > Section 4.1:
>> >> >> >> >
>> >> >> >> > Congestion control mechanisms for = multicast may operate on
>> >> longer
>> >> >> >> > =C2=A0 =C2=A0timescales than for u= nicast (e.g., due to the higher group
>> >> RTT
>> >> >> of a
>> >> >> >> > =C2=A0 =C2=A0heterogeneous group);= appropriate methods are particularly
>> >> for
>> >> >> any
>> >> >> >> > =C2=A0 =C2=A0multicast session wer= e all or part of the multicast
>> >> distribution
>> >> >> >> tree
>> >> >> >> > =C2=A0 =C2=A0spans an access netwo= rk (e.g., a home gateway).
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > The above isn't relevant for a= pplication based CC mechanism.
>> In
>> >> >> fact,
>> >> >> >> an
>> >> >> >> > application-based mechanism may of= ten operate faster than any
>> >> RTT
>> >> >> >> > dependent
>> >> >> >> > mechanism. I think we should eithe= r remove this paragraph
>> >> entirely
>> >> >> or
>> >> >> >> > restructure it to make the point t= hat application based CC
>> >> operates
>> >> >> >> > without
>> >> >> >> > dependency on RTT.
>> >> >> >> >
>> >> >> >> > Greg
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Mon, Jun 16, 2014 at 1:50 AM, E= ggert, Lars
>> <lars@netapp.com>
>> >> >> wrote:
>> >> >> >> >
>> >> >> >> >> Hi,
>> >> >> >> >>
>> >> >> >> >> Gorry and me have started to p= ut together an update to
>> RFC5405
>> >> in
>> >> >> >> light
>> >> >> >> >> of
>> >> >> >> >> the recent discussions. Commen= ts welcome.
>> >> >> >> >>
>> >> >> >> >> Lars
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Begin forwarded message:
>> >> >> >> >>
>> >> >> >> >> > From: <internet-drafts@ietf.org>
>> >> >> >> >> > Subject: New Version Noti= fication for
>> >> >> >> >> draft-eggert-tsvwg-rfc5405bis-= 00.txt
>> >> >> >> >> > Date: June 14, 2014 at 12= :14:42 GMT+2
>> >> >> >> >> > To: Lars Eggert <lars@netapp.com>, Godred Fairhurst <= ;
>> >> >> >> >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst
>> <gorry@erg.abdn.ac.uk>,
>> >> >> Lars
>> >> >> >> >> Eggert <lars@netapp.com>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > A new version of I-D, dra= ft-eggert-tsvwg-rfc5405bis-00.txt
>> >> >> >> >> > has been successfully sub= mitted by Lars Eggert and posted
>> to
>> >> the
>> >> >> >> >> > IETF repository.
>> >> >> >> >> >
>> >> >> >> >> > Name: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 draft-eggert-tsvwg-rfc5405bis
>> >> >> >> >> > Revision: =C2=A0 =C2=A0 0= 0
>> >> >> >> >> > Title: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UDP Usage Guidelines
>> >> >> >> >> > Document date: =C2=A0 =C2= =A0 =C2=A0 =C2=A02014-06-14
>> >> >> >> >> > Group: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>> >> >> >> >> > Pages: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A036
>> >> >> >> >> > URL:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.ietf.org/internet-drafts/dr= aft-eggert-tsvwg-rfc5405bis-00.txt
>> >> >> >> >> > Status:
>> >> >> >> >>
>> https://datatracker.ietf.org/doc/draft-eggert-t= svwg-rfc5405bis/
>> >> >> >> >> > Htmlized:
>> >> >> >> >> http://tools.ie= tf.org/html/draft-eggert-tsvwg-rfc5405bis-00
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > Abstract:
>> >> >> >> >> > =C2=A0 The User Datagram = Protocol (UDP) provides a minimal
>> >> >> >> message-passing
>> >> >> >> >> > =C2=A0 transport that has= no inherent congestion control
>> >> mechanisms.
>> >> >> >> >> > =C2=A0 Because congestion= control is critical to the stable
>> >> operation
>> >> >> of
>> >> >> >> >> the
>> >> >> >> >> > =C2=A0 Internet, applicat= ions and other protocols that choose
>> to
>> >> use
>> >> >> UDP
>> >> >> >> as
>> >> >> >> >> > =C2=A0 an Internet transp= ort must employ mechanisms to prevent
>> >> >> >> congestion
>> >> >> >> >> > =C2=A0 collapse and to es= tablish some degree of fairness with
>> >> >> concurrent
>> >> >> >> >> > =C2=A0 traffic. =C2=A0The= y may also need to implement additional
>> >> >> mechanisms,
>> >> >> >> >> > =C2=A0 depending on how t= hey use UDP.
>> >> >> >> >> >
>> >> >> >> >> > =C2=A0 This document prov= ides guidelines on the use of UDP for
>> the
>> >> >> >> >> designers
>> >> >> >> >> > =C2=A0 of applications, t= unnels and other protocols that use
>> UDP.
>> >> >> >> >> > =C2=A0 Congestion control= guidelines are a primary focus, but
>> the
>> >> >> >> document
>> >> >> >> >> > =C2=A0 also provides guid= ance on other topics, including
>> message
>> >> >> sizes,
>> >> >> >> >> > =C2=A0 reliability, check= sums, and middlebox traversal.
>> >> >> >> >> >
>> >> >> >> >> > =C2=A0 If published as an= RFC, this document will obsolete
>> >> RFC5405.
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > Please note that it may t= ake a couple of minutes from the
>> >> time
>> >> >> of
>> >> >> >> >> submission
>> >> >> >> >> > until the htmlized versio= n and diff are available at
>> >> >> >> tools.ietf.org.
>> >> >> >> >> >
>> >> >> >> >> > The IETF Secretariat
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



--001a11c326aa0b27b704fc0952d5-- From nobody Wed Jun 18 10:40: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 58EAD1A02B4 for ; Wed, 18 Jun 2014 10:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 AHAuv3nPUQCT for ; Wed, 18 Jun 2014 10:40:22 -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 519EC1A00D5 for ; Wed, 18 Jun 2014 10:40:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5IHcu9N009871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 10:38:57 -0700 (PDT) Message-ID: <53A1CEB0.7080807@isi.edu> Date: Wed, 18 Jun 2014 10:38:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Eggert, Lars" , Colin Perkins References: <538C9AFD.2010006@erg.abdn.ac.uk> <1604B9A0-79F7-4D06-AD94-ADCE49D4CDEF@netapp.com> In-Reply-To: <1604B9A0-79F7-4D06-AD94-ADCE49D4CDEF@netapp.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/Vm7RDvi2TVRqq3h9RItf06xqXis Cc: Gorry Fairhurst , "tsvwg@ietf.org" Subject: Re: [tsvwg] Request for WG support for Circuit Breakers drfat. 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, 18 Jun 2014 17:40:23 -0000 +1, and IMO BCP. On 6/16/2014 5:44 AM, Eggert, Lars wrote: > On 2014-6-16, at 12:16, Colin Perkins wrote: >> I think this more general requirements and motivating discussion is valuable, and I would support this draft becoming a TSVWG work item. > > Agreed. > > (Modulo that I'm not sure that PS is the right target here. Informational or BCP might be better.) > > Lars > From nobody Wed Jun 18 11:26:45 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 AD8AC1A02E0; Wed, 18 Jun 2014 11:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 5F0wecDvr0lM; Wed, 18 Jun 2014 11:26:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D5B1A02D8; Wed, 18 Jun 2014 11:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4614; q=dns/txt; s=iport; t=1403115998; x=1404325598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9vzcqOv9TIRC0Yf0UHJZ2ZmQYqsCak0slbKL6hdx8XQ=; b=mr1wVtpLsstXfzQXboGrCZZ58L/OZfm/1tpvcIlFr9HwU/wn58VLf8Du 0//Ks13RsferXoI3tKJQO0nmjzUjp8GpZ5fvIujcr8FctD5jxhDiYP7p4 8tVpuQ6O7wpbI0YIFQq/yCsPtMJd91qAStl1dxYn1Bl84YYV0J3sttwum k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAIAKLYoVOtJA2J/2dsb2JhbABaDoJ/UlqqBwwBAQEBAQEFAZkoAYELFnWEAwEBAQQ6PwwEAgEIEQQBAQsDEQkHMhQJCAIEAQ0FCIg6Dc0sF4ViiGIxBwaDJ4EWBJwGkhWDAEKCMA X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="54158211" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 18 Jun 2014 18:26:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5IIQbL9030113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 18:26:37 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.38]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 13:26:36 -0500 From: "Subha Dhesikan (sdhesika)" To: "Bless, Roland (TM)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 Thread-Index: AQHPhkO4fRrG2WYKYkKaZZx78AMF65t3Nd7A Date: Wed, 18 Jun 2014 18:26:36 +0000 Message-ID: References: <5399AD7F.20805@kit.edu> In-Reply-To: <5399AD7F.20805@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.209.62] 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/dE5NmltbTpttalEgZhhcsfKgm6w Cc: "dart@ietf.org" Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 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, 18 Jun 2014 18:26:40 -0000 Roland,=20 Thanks for your comments. Inline: -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Bless, Roland (TM) Sent: Thursday, June 12, 2014 6:39 AM To: tsvwg@ietf.org Cc: dart@ietf.org Subject: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 Hi, some remarks on draft-ietf-tsvwg-rtcweb-qos-00: Sec. 2: The mitigation for such action is through an authorization mechanism. An authorization mechanism alone is probably not sufficient, because DS bou= ndary nodes may need to police (e.g., remark/drop) incoming traffic accordi= ng to some agreed/negotiated traffic profile for some of the PHBs, e.g., th= e EF PHB does not work properly if its traffic class is overloaded (see bel= ow). SD: Agreed. The previous line states: " Therefore, the DSCP value may be re= marked at the network edge through policy to any other DSCP value, including best effort.". = There is already a mention that apckers may be remarked or dropped and any = additional mitigation is outside the scope of this draft. Sec. 4: The below uses the concept of a media flow, however these are commonly not equivalent to a transport flow, i.e. as defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). I think one should try to use definitions that do not depend on the classif= ier type like 5-tuple, because as Brian already mentioned, for IPv6 a 3-tup= le (IPsrc, IPdst, Flow Label) may be sufficient and header fields of the 5-= tuple are not always accessible. I liked the definition of microflow in DiffServ as being an application-to-= application flow of packets, usually being identified by that well known 5-= tuple. For elements within the network microflows are usually the most fine= grained distinction level for flows (except when you apply multi-field cla= ssifier that do some DPI and add the SSRC etc.). (nit: is probably a word like "text" missing in the first cited sentence above?) Proper definitions for media flow, RTP session, transport flow etc. may help to avoid confusion, so maybe one could try to combine efforts with= draft-york-dart-dscp-rtp-00? SD:. There has been some discussion on the use of the word "media flow". B= etween the webrtc group and tsvwg, these words are defined or being defined= . I will further check on it. Sec. 5: SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. The problem with using EF is that if too many EF marked packets are injecte= d into a DS domain, they probably void the EF properties for other users wi= thin this domain (background is that the service rate of EF packets on a gi= ven output interface must exceed their arrival rate at that interface over = long and short time intervals - this is usually checked by admission contro= l before use and policing at DS boundary nodes during use). Therefore, mayb= e some discussion w.r.t. RFC5865 http://tools.ietf.org/html/rfc5865 may be = useful. SD: Agreed that admission control is very useful and relevant. This draft i= s intended for the selection and use of the right DSCP for webrtc media flo= ws. There is a mention of over-subscription in the beginning.=20 The above table assumes that packets marked with CS1 is treated as "less than best effort". However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the priority of the packets may be changed from what is intended. BTW, there is no "less than best effort" PHB defined, but a Lower Effort Pe= r-Domain Behavior (PDB) in RFC 3662 (http://tools.ietf.org /html/rfc3662). = This RFC is also the source for the recommendation of using the CS-1 codepo= int for that purpose, so you may considering referencing it. SD: Sounds good. Will do. If a packet enters a QoS domain that has no support for the above defined Data Types/Application (service) classes, then the network node at the edge will remark the DSCP value based on policies. Yes, but even if there is support for these classes traffic conditioning (e= .g., remarking/dropping etc.) may be necessary and applied. Remarking to di= fferent PHBs may also lead to packet reordering within a media flow?! SD: Remarking/dropping may occur, which is mentioned in the draft. =20 Thanks again for the review of the draft. Regards, Subha Regards, Roland From nobody Mon Jun 23 12:09:29 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 9563C1B2C0F; Mon, 23 Jun 2014 12:09:22 -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 APZ7iZ84XDeH; Mon, 23 Jun 2014 12:09:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAB81B2C49; Mon, 23 Jun 2014 12:08:34 -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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623190834.25896.59277.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 12:08:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/wdPFAdyY8xKf_euOh2t4feAFd0Y Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-01.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: Mon, 23 Jun 2014 19:09:22 -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 : DSCP and other packet markings for RTCWeb QoS Authors : Subha Dhesikan Cullen Jennings Dan Druta Paul Jones James Polk Filename : draft-ietf-tsvwg-rtcweb-qos-01.txt Pages : 7 Date : 2014-06-23 Abstract: Many networks, such as service provider and enterprise networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per-hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 23 12:11:43 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 926441B2C06; Mon, 23 Jun 2014 12:11:39 -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 w84xbhwMBLc5; Mon, 23 Jun 2014 12:11:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490D1A050E; Mon, 23 Jun 2014 12:11:32 -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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 12:11:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/o3EEmBed6m86t6g58sNMzBfQmok Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.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: Mon, 23 Jun 2014 19:11:39 -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 : DSCP and other packet markings for RTCWeb QoS Authors : Subha Dhesikan Cullen Jennings Dan Druta Paul Jones James Polk Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt Pages : 7 Date : 2014-06-23 Abstract: Many networks, such as service provider and enterprise networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per-hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 24 01:30:34 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 228D71B299A; Tue, 24 Jun 2014 01:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWUgQ4kxtbUE; Tue, 24 Jun 2014 01:30:27 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 88B651B299F; Tue, 24 Jun 2014 01:30:26 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1WzM7R-0002lx-GS; Tue, 24 Jun 2014 10:30:21 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id B0523A804D5; Tue, 24 Jun 2014 10:30:24 +0200 (CEST) Message-ID: <53A93720.6040604@kit.edu> Date: Tue, 24 Jun 2014 10:30:24 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Subha Dhesikan (sdhesika)" , "tsvwg@ietf.org" References: <5399AD7F.20805@kit.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1403598621. Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/TaHlhE9OLTw4KxiTx85pWffG5t0 Cc: "dart@ietf.org" Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00 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, 24 Jun 2014 08:30:30 -0000 Hi Subha, thanks for you reply, see comments inline: > An authorization mechanism alone is probably not sufficient, because > DS boundary nodes may need to police (e.g., remark/drop) incoming > traffic according to some agreed/negotiated traffic profile for some > of the PHBs, e.g., the EF PHB does not work properly if its traffic > class is overloaded (see below). > > SD: Agreed. The previous line states: " Therefore, the DSCP value > may be remarked at the network edge through policy to any other DSCP > value, including best effort.". There is already a mention that > apckers may be remarked or dropped and any additional mitigation is > outside the scope of this draft. Unfortunately, this doesn't address my comment. DSCP remarking by provider policy is somewhat different from having policers installed (e.g., a token bucket w/ marker and dropper) that perform traffic conditioning according to some installed traffic profile. Static remarking of DSCPs may be caused by using a different DCSP/PHB mapping or lack of DiffServ support etc. which is slightly different. > The problem with using EF is that if too many EF marked packets are > injected into a DS domain, they probably void the EF properties for > other users within this domain (background is that the service rate of > EF packets on a given output interface must exceed their arrival rate at > that interface over long and short time intervals - this is usually > checked by admission control before use and policing at DS boundary > nodes during use). Therefore, maybe some discussion w.r.t. RFC5865 > http://tools.ietf.org/html/rfc5865 may be useful. > SD: Agreed that admission control is very useful and relevant. This > draft is intended for the selection and use of the right DSCP for > webrtc media flows. There is a mention of over-subscription in the > beginning. Sure, however, my point was that simply injecting traffic marked with a DSCP for a PHB that normally requires prior admission control is somewhat problematic: either guarantees for already admitted flows are violated or such traffic has to be dropped. > If a packet enters a QoS domain that has no support for the above > defined Data Types/Application (service) classes, then the network > node at the edge will remark the DSCP value based on policies. > > Yes, but even if there is support for these classes traffic > conditioning (e.g., remarking/dropping etc.) may be necessary and > applied. Remarking to different PHBs may also lead to packet > reordering within a media flow?! >SD: Remarking/dropping may occur, which is mentioned in the draft. Same issue as above: remarking caused by a static DS domain policy (PHBx -> PHBy) is different from remarking and other actions that boundary nodes may perform for individual flows according to traffic profiles. Regards, Roland From nobody Tue Jun 24 05:10:34 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 60C4E1B2871 for ; Tue, 24 Jun 2014 05:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JypgA1WhQVe9 for ; Tue, 24 Jun 2014 05:10:27 -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 87AAC1B28E6 for ; Tue, 24 Jun 2014 05:10:27 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 2A4B32B4540; Tue, 24 Jun 2014 13:10:26 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E2AE52B4271; Tue, 24 Jun 2014 13:10:24 +0100 (BST) Message-ID: <53A96AB0.9080507@erg.abdn.ac.uk> Date: Tue, 24 Jun 2014 13:10:24 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tsvwg WG , Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/75S6csuCEwWWn45NKynln123Llo Subject: [tsvwg] SCTP NAPT/NAT Support X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 12:10:31 -0000 Last IETF tsvwg discussed the possibility of merging two milestones in TSVWG relating to SCTP and NAPT/NAT, to result in a single document on this topic. The current milestones are: * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as PS * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP I hope that whatever way this proceeds, we suggest the document(s) clearly identify the parts that relate to: (1) implementing a NAT/NAPT and (2) the support needed for SCTP implementors/users use a NAPT As I recall, there was little opposition to this restructuring of the work, and this email is to make the list aware of this proposal. Please send comments if any to the list, this will help the Chairs make a decision on how best to proceed. Best wishes, Gorry, David and James (tsvwg Co-Chairs) From nobody Tue Jun 24 05:35: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 E862E1B28B3 for ; Tue, 24 Jun 2014 05:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dS0aWMUKHmb9 for ; Tue, 24 Jun 2014 05:35:29 -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 2FA901B28C2 for ; Tue, 24 Jun 2014 05:35:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJE36122; Tue, 24 Jun 2014 12:35:26 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 13:35:25 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml703-chm.china.huawei.com ([169.254.5.42]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 05:35:20 -0700 From: Lucy yong To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Request for WG support for Circuit Breakers draft. Thread-Index: AQHPj6jD9cnpaOOboU2UpZGzRJNhZw== Date: Tue, 24 Jun 2014 12:35:20 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453ADBE9@dfweml701-chm.china.huawei.com> References: <538C9AFD.2010006@erg.abdn.ac.uk> In-Reply-To: <538C9AFD.2010006@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.229] 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/Z1PFM72_r_3BbvOBtEOxtsXvbBI Subject: Re: [tsvwg] Request for WG support for Circuit Breakers draft. 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, 24 Jun 2014 12:35:32 -0000 Hi Gorry, I read this draft. It is well written. I support the adoption.=20 Here are some comments. If the intention of this draft is to provide an implementation for foo-in-u= dp, it may be questionable its applicability to it. The solution requires i= ngress and egress doing packet measurement/count; and ingress may be sender= or tunnel ingress.=20 In foo-in-udp, src udp port is used as entropy. So it will result many tunn= el ingresses at a sender. Measurement at each tunnel ingress raises a big c= oncern on the performance and scalability. If measurement at sender, the fl= ows from sender to receiver may traverse different paths, I wonder if such = measurement at sender and receiver will address the issue or not. For examp= le, if only one path is congested, others are not.=20 For foo-in-udp, we should draw multiple paths between ingress and egress in= figure 1, and the implementation need to factor that in. If this implementation is for single path between ingress and egress, it wo= rks. We need clarify the applicability of this solution.=20 Thanks, Lucy -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst Sent: Monday, June 02, 2014 10:41 AM To: tsvwg@ietf.org Subject: [tsvwg] Request for WG support for Circuit Breakers draft. As an individual author, to the WG (and the TSVWG Chairs): I wrote the draft below in response to the large number of side discussions= and meeting minutes spent on this topic at the last IETF.=20 I'd be very keen to see (or hear) feedback on this draft, and whether this = document could be a reasonable basis for a TSVWG document on this topic. http://tools.ietf.org/html/draft-fairhurst-tsvwg-circuit-breaker-01 Best wishes, Gorry (only as the author of this submission) From nobody Tue Jun 24 06:28: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 83FA81B29EF for ; Tue, 24 Jun 2014 06:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 BSXbpBuLNWxF for ; Tue, 24 Jun 2014 06:28:45 -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 35CAA1B29E0 for ; Tue, 24 Jun 2014 06:28:39 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 260232B4540; Tue, 24 Jun 2014 14:28:38 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1104E2B4271; Tue, 24 Jun 2014 14:28:37 +0100 (BST) Message-ID: <53A97D04.6050909@erg.abdn.ac.uk> Date: Tue, 24 Jun 2014 14:28:36 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tsvwg WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/w4nJIJ4XXcIia14gg4U3Zr7zeb8 Cc: draft-ietf-tsvwg-sctp-dtls-encaps@tools.ietf.org Subject: [tsvwg] WGLC Follow-Up: draft-ietf-tsvwg-sctp-dtls-encaps X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:28:48 -0000 The WGLC for the above document ended 28th February 2014, and follow-up discussions resulted in a revised draft. I am now starting to prepare for submission of the above document for requested publication. Please find detailed comments/questions about the text below. Best wishes, Gorry Fairhurst. (TSVWG Co-Chair) --- ABSTRACT: "Using encapsulation method described in this document, SCTP is..." ^ - insert /the/ ? --- ABSTRACT: "As a consequence, the SCTP associations are single homed." - This final statement is not clear, although true. Please add text to explain to the reader why this is needed in the abstract. Could you say something that follows this below, and also explain why in section 6.1? "The security properties of this encapsulation limit usage to single-homed SCTP associations." --- Section 5: "a safe value for the path MTU has to be used by the SCTP stack." - How do you choose? - please specify a default or a method. --- Section 5: "Differentiated services code point (DSCP) " - reference needed. --- Section 5: "explicit congestion notifications (ECN)" - reference needed. --- Section 5: "SCTP performs segmentation and reassembly based on the path MTU. Therefore the DTLS layer MUST NOT use any compression algorithm. The DTLS MUST support sending messages larger than the current path MTU. This might result in sending IP level fragmented messages." - I wonder if some reordering of paras within teh section could gather all the size-related topics in one part of the section? --- Section 6: - I am surprised this section does not mention how to handle any path changes, should PMTUD be triggered following known changes, for instance? Does this affect the SCTP CC state? --- Section 6.1: /doesn't deal/does not deal/ - please change. --- Section 6.1: "All SCTP associations are single-homed." Could you add something like: ", because DTLS does not expose any address management to its upper layer." --- Section 6.2: "The padding extension defined in [RFC4820] MUST be supported and used for probe packets when performing path MTU discovery as specified in [RFC4821]." - Is this section relevant when DTLS implements PMTUD, please explain? --- References: A later version (-10) exists ofdraft-ietf-rtcweb-overview-09 A later version (-10) exists of draft-ietf-rtcweb-data-channel-08 --- The requirement to use SCTP/DTLS appears to also be cited in draft-ietf-rtcweb-overview-09, section 5.5, which requires normative use of SCTP/DTLS, but this document is not cited in the current document, I think it should be, if not why not? From nobody Tue Jun 24 07:17:05 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 2FC231B2A4D for ; Tue, 24 Jun 2014 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 0jUpsdw2xHgf for ; Tue, 24 Jun 2014 07:17:00 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB681B2A43 for ; Tue, 24 Jun 2014 07:17:00 -0700 (PDT) Received: from [192.168.1.200] (p508F3793.dip0.t-ipconnect.de [80.143.55.147]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E28841C1049A4; Tue, 24 Jun 2014 16:16:57 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: <53A96AB0.9080507@erg.abdn.ac.uk> Date: Tue, 24 Jun 2014 16:16:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C72E1F8-1369-49C6-B404-55CE6C45E416@fh-muenster.de> References: <53A96AB0.9080507@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/T7n1-TX834Mme-ds2wfrXwV6D9c Cc: tsvwg WG Subject: Re: [tsvwg] SCTP NAPT/NAT Support 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, 24 Jun 2014 14:17:02 -0000 On 24 Jun 2014, at 14:10, Gorry Fairhurst wrote: >=20 > Last IETF tsvwg discussed the possibility of merging two milestones in = TSVWG relating to SCTP and NAPT/NAT, to result in a single document on = this topic. >=20 > The current milestones are: > * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as PS > * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP >=20 > I hope that whatever way this proceeds, we suggest the document(s) = clearly identify the parts that relate to: > (1) implementing a NAT/NAPT > and (2) the support needed for SCTP implementors/users use a NAPT >=20 > As I recall, there was little opposition to this restructuring of the = work, and this email is to make the list aware of this proposal. > Please send comments if any to the list, this will help the Chairs = make a decision on how best to proceed. I think it really makes sense to combine them into a single document. Best regards Michael >=20 > Best wishes, >=20 > Gorry, David and James > (tsvwg Co-Chairs) >=20 >=20 >=20 From nobody Tue Jun 24 08:27: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 5F66F1B2D80 for ; Tue, 24 Jun 2014 08:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 jQnhsKirQQiN for ; Tue, 24 Jun 2014 08:27:02 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED381B2D9C for ; Tue, 24 Jun 2014 08:23:15 -0700 (PDT) Received: from HT02.win.uni-due.de ([132.252.185.215]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id s5OFNAjV019388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 17:23:12 +0200 Received: from ccr02.win.uni-due.de ([169.254.2.187]) by HT02.win.uni-due.de ([132.252.190.234]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 17:23:11 +0200 From: "Becke, Martin" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] SCTP NAPT/NAT Support Thread-Index: AQHPj6VTKmRXG77/L0+879sdojA9RZuAP9SA Date: Tue, 24 Jun 2014 15:23:11 +0000 Message-ID: <45015BD7-8538-4469-8308-8C033E041C5D@uni-due.de> References: <53A96AB0.9080507@erg.abdn.ac.uk> In-Reply-To: <53A96AB0.9080507@erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.252.185.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/8UeACDHfgvSJ-oVGLm5Vt951J_A Cc: Michael Tuexen , tsvwg WG Subject: Re: [tsvwg] SCTP NAPT/NAT Support 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, 24 Jun 2014 15:27:07 -0000 IMPOV it is the best to have it in one document but I am not aware of any d= rawbacks. Are there any arguments to have it in two?=20 Best, Martin=20 Am 24.06.2014 um 14:10 schrieb Gorry Fairhurst : >=20 > Last IETF tsvwg discussed the possibility of merging two milestones in TS= VWG relating to SCTP and NAPT/NAT, to result in a single document on this t= opic. >=20 > The current milestones are: > * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as PS > * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP >=20 > I hope that whatever way this proceeds, we suggest the document(s) clearl= y identify the parts that relate to: > (1) implementing a NAT/NAPT > and (2) the support needed for SCTP implementors/users use a NAPT >=20 > As I recall, there was little opposition to this restructuring of the wor= k, and this email is to make the list aware of this proposal. > Please send comments if any to the list, this will help the Chairs make a= decision on how best to proceed. > Best wishes, >=20 > Gorry, David and James > (tsvwg Co-Chairs) >=20 >=20 From nobody Tue Jun 24 09:45: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 157D51B2BC9 for ; Tue, 24 Jun 2014 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 8doE6iSO2eAM for ; Tue, 24 Jun 2014 09:45:31 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22881B2BB1 for ; Tue, 24 Jun 2014 09:45:30 -0700 (PDT) Received: from [192.168.1.200] (p508F3793.dip0.t-ipconnect.de [80.143.55.147]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DD8C31C1049A4; Tue, 24 Jun 2014 18:45:27 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: <45015BD7-8538-4469-8308-8C033E041C5D@uni-due.de> Date: Tue, 24 Jun 2014 18:45:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <959213DE-39B5-4F49-804E-CC0AB35F56A2@fh-muenster.de> References: <53A96AB0.9080507@erg.abdn.ac.uk> <45015BD7-8538-4469-8308-8C033E041C5D@uni-due.de> To: Martin Becke X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/nbWlSRUCL18Kdh65y1RSVKvidgo Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] SCTP NAPT/NAT Support 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, 24 Jun 2014 16:45:32 -0000 On 24 Jun 2014, at 17:23, Becke, Martin wrote: > IMPOV it is the best to have it in one document but I am not aware of = any drawbacks. > Are there any arguments to have it in two?=20 No. Except that it is some work to merge them, but it will be much = easier to read in the end... Best regards Michael >=20 > Best, > Martin=20 >=20 >=20 > Am 24.06.2014 um 14:10 schrieb Gorry Fairhurst : >=20 >>=20 >> Last IETF tsvwg discussed the possibility of merging two milestones = in TSVWG relating to SCTP and NAPT/NAT, to result in a single document = on this topic. >>=20 >> The current milestones are: >> * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as = PS >> * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP >>=20 >> I hope that whatever way this proceeds, we suggest the document(s) = clearly identify the parts that relate to: >> (1) implementing a NAT/NAPT >> and (2) the support needed for SCTP implementors/users use a NAPT >>=20 >> As I recall, there was little opposition to this restructuring of the = work, and this email is to make the list aware of this proposal. >> Please send comments if any to the list, this will help the Chairs = make a decision on how best to proceed. >> Best wishes, >>=20 >> Gorry, David and James >> (tsvwg Co-Chairs) >>=20 >>=20 >=20 >=20 From nobody Tue Jun 24 09:47:53 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 35E491B28CD for ; Tue, 24 Jun 2014 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_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 9ObfwJMJUd7U for ; Tue, 24 Jun 2014 09:47:49 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7021A0653 for ; Tue, 24 Jun 2014 09:47:49 -0700 (PDT) Received: from [192.168.1.200] (p508F3793.dip0.t-ipconnect.de [80.143.55.147]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3DEC91C1049A4; Tue, 24 Jun 2014 18:47:47 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: Date: Tue, 24 Jun 2014 18:47:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53A96AB0.9080507@erg.abdn.ac.uk> To: Randall Stewart X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/I3cn4WvmhzfGD6enWCG2aUWwNCo Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] SCTP NAPT/NAT Support 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, 24 Jun 2014 16:47:51 -0000 On 24 Jun 2014, at 18:05, Randall Stewart = wrote: > Gorry: >=20 > I really do agree that this makes complete sense. The document was > originally one and for some unknown reason (I don=92t remember) we = split I think the reason was that the NAT stuff was requested to be handled in BEHAVE as an informational document, but we needed to protocol mechanisms in a standards track document which was thought to be better handled in TSVWG. Since we deal now with the documents in a single WG, we can merge them. Best regards Michael > it into two. This makes reading it very difficult, if you start = reading one > often you must get the other out and read that in combination if you = want > it to make much sense.. >=20 > Putting them together makes things *much* easier and more clear :-) >=20 > R > On Jun 24, 2014, at 8:10 AM, Gorry Fairhurst = wrote: >=20 >>=20 >> Last IETF tsvwg discussed the possibility of merging two milestones = in TSVWG relating to SCTP and NAPT/NAT, to result in a single document = on this topic. >>=20 >> The current milestones are: >> * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as = PS >> * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP >>=20 >> I hope that whatever way this proceeds, we suggest the document(s) = clearly identify the parts that relate to: >> (1) implementing a NAT/NAPT >> and (2) the support needed for SCTP implementors/users use a NAPT >>=20 >> As I recall, there was little opposition to this restructuring of the = work, and this email is to make the list aware of this proposal. >> Please send comments if any to the list, this will help the Chairs = make a decision on how best to proceed. >>=20 >> Best wishes, >>=20 >> Gorry, David and James >> (tsvwg Co-Chairs) >>=20 >>=20 >=20 > ----- > Randall R. Stewart > rstewart@adaranetworks.com >=20 >=20 >=20 >=20 From nobody Tue Jun 24 11:21:45 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 72C221B2DC2 for ; Tue, 24 Jun 2014 11:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 daqpDmKab8ip for ; Tue, 24 Jun 2014 11:21:33 -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 7008E1A03F5 for ; Tue, 24 Jun 2014 11:18:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5OIIMDP022433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 11:18:23 -0700 (PDT) Message-ID: <53A9C0EE.90903@isi.edu> Date: Tue, 24 Jun 2014 11:18:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lucy yong , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" References: <538C9AFD.2010006@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D453ADBE9@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453ADBE9@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9JRwyP1QIz0LuSFee4y3mSaMuz4 Subject: Re: [tsvwg] Request for WG support for Circuit Breakers draft. 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, 24 Jun 2014 18:21:37 -0000 On 6/24/2014 5:35 AM, Lucy yong wrote: > Hi Gorry, > > I read this draft. It is well written. I support the adoption. > > Here are some comments. > > If the intention of this draft is to provide an implementation for > foo-in-udp, it may be questionable its applicability to it. The solution > requires ingress and egress doing packet measurement/count; and ingress > may be sender or tunnel ingress. > > In foo-in-udp, src udp port is used as entropy. ... These are issues regarding the tunnel encapsulation mechanism, which is independent of how the aggregate tunneled traffic has a circuit breaker. They are out of scope for this doc, IMO. The are more likely in scope for the INTAREA tunnels doc (already a WG item, that Mark and I are revising). Joe From nobody Tue Jun 24 11:40: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 5E31C1B2BD8 for ; Tue, 24 Jun 2014 11:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dlgIV2ugRKOm for ; Tue, 24 Jun 2014 11:40:21 -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 33C8C1B2BC3 for ; Tue, 24 Jun 2014 11:40:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGH52358; Tue, 24 Jun 2014 18:40:19 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 19:40:18 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 11:40:09 -0700 From: Lucy yong To: Joe Touch , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Request for WG support for Circuit Breakers draft. Thread-Index: AQHPj6jD9cnpaOOboU2UpZGzRJNhZ5uBB2QA//+L1ZA= Date: Tue, 24 Jun 2014 18:40:08 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453ADF26@dfweml701-chm.china.huawei.com> References: <538C9AFD.2010006@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D453ADBE9@dfweml701-chm.china.huawei.com> <53A9C0EE.90903@isi.edu> In-Reply-To: <53A9C0EE.90903@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.229] 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/53ryrXZ82KkN0-n2TfMVNCjrCww Subject: Re: [tsvwg] Request for WG support for Circuit Breakers draft. 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, 24 Jun 2014 18:40:24 -0000 Hi Joe, =20 On 6/24/2014 5:35 AM, Lucy yong wrote: > Hi Gorry, > > I read this draft. It is well written. I support the adoption. > > Here are some comments. > > If the intention of this draft is to provide an implementation for=20 > foo-in-udp, it may be questionable its applicability to it. The=20 > solution requires ingress and egress doing packet measurement/count;=20 > and ingress may be sender or tunnel ingress. > > In foo-in-udp, src udp port is used as entropy. ... These are issues regarding the tunnel encapsulation mechanism, which is ind= ependent of how the aggregate tunneled traffic has a circuit breaker. They are out of scope for this doc, IMO. The are more likely in scope for t= he INTAREA tunnels doc (already a WG item, that Mark and I are revising). [Lucy] This is the reason I ask the clarification on this solution. In my u= nderstanding, the motivation of the draft is because of the proposals of gr= e-in-udp, mpls-in-udp, vxlan, etc, where udp tunnel encapsulation is used a= nd udp src port is used as entropy. There were extensive discussions on thi= s udp tunnel approach, and using a circuit breaker was strongly recommended= for self/automatically resolving a congestion problem that may happen in u= nderlying IP network. I may be wrong and, now, ask if proposed solution in = the draft applies to foo-in-udp or not.=20 Gre-in-udp is now in the charter of TSVWG. We like to resolve the concerns = on it here without going to another area. Lucy From nobody Tue Jun 24 11:47: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 DA8281B2BF2 for ; Tue, 24 Jun 2014 11:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 UCwdl7wNdu7e for ; Tue, 24 Jun 2014 11:47:26 -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 43E7E1B2BF3 for ; Tue, 24 Jun 2014 11:47:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5OIkkD1028602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 11:46:46 -0700 (PDT) Message-ID: <53A9C796.2020903@isi.edu> Date: Tue, 24 Jun 2014 11:46:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lucy yong , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" References: <538C9AFD.2010006@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D453ADBE9@dfweml701-chm.china.huawei.com> <53A9C0EE.90903@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D453ADF26@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453ADF26@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/TDYe4oS3sZVtGfiLOEmUYc6bYkw Subject: Re: [tsvwg] Request for WG support for Circuit Breakers draft. 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, 24 Jun 2014 18:47:28 -0000 On 6/24/2014 11:40 AM, Lucy yong wrote: > Hi Joe, > > > On 6/24/2014 5:35 AM, Lucy yong wrote: >> Hi Gorry, >> >> I read this draft. It is well written. I support the adoption. >> >> Here are some comments. >> >> If the intention of this draft is to provide an implementation for >> foo-in-udp, it may be questionable its applicability to it. The >> solution requires ingress and egress doing packet measurement/count; >> and ingress may be sender or tunnel ingress. >> >> In foo-in-udp, src udp port is used as entropy. > ... > > These are issues regarding the tunnel encapsulation mechanism, which > is independent of how the aggregate tunneled traffic has a circuit > breaker. > > They are out of scope for this doc, IMO. The are more likely in scope > for the INTAREA tunnels doc (already a WG item, that Mark and I are > revising). > > [Lucy] This is the reason I ask the clarification on this solution. > In my understanding, the motivation of the draft is because of the > proposals of gre-in-udp, mpls-in-udp, vxlan, etc, where udp tunnel > encapsulation is used and udp src port is used as entropy. There were > extensive discussions on this udp tunnel approach, and using a > circuit breaker was strongly recommended for self/automatically > resolving a congestion problem that may happen in underlying IP > network. I may be wrong and, now, ask if proposed solution in the > draft applies to foo-in-udp or not. > > Gre-in-udp is now in the charter of TSVWG. We like to resolve the > concerns on it here without going to another area. These are all cross-area issues ultimately; it's not going to be possible for any doc - including the tunnels one in INTAREA - to be handled exclusively within one area. Joe From nobody Tue Jun 24 22:40:28 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 D0CB51B2ACE for ; Tue, 24 Jun 2014 22:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Gqn4yXa5bwIr for ; Tue, 24 Jun 2014 22:40:23 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FB21B2ACD for ; Tue, 24 Jun 2014 22:40:21 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-24-53aa60c3abdb Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.3A.25910.3C06AA35; Wed, 25 Jun 2014 07:40:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.222]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 07:40:18 +0200 From: Salvatore Loreto To: Michael Tuexen Thread-Topic: [tsvwg] SCTP NAPT/NAT Support Thread-Index: AQHPj6VPGJtHbb1MdUujGTsDU7BRcJuALRQAgAEB/gA= Date: Wed, 25 Jun 2014 05:40:17 +0000 Message-ID: References: <53A96AB0.9080507@erg.abdn.ac.uk> <1C72E1F8-1369-49C6-B404-55CE6C45E416@fh-muenster.de> In-Reply-To: <1C72E1F8-1369-49C6-B404-55CE6C45E416@fh-muenster.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <717F623D98FC5844863A24E05112D373@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje7hhFXBBjM2K1m8bpvNaHHszV02 iwlLH7E6MHv0fH7B5NEz5TSrx5IlP5kCmKO4bFJSczLLUov07RK4Mqbue8dY8I+z4tae2UwN jB/Yuxg5OSQETCRun1rDCmGLSVy4t56ti5GLQ0jgKKPE/dWvGSGcJYwS0/Z8A+tgEzCTeP5w CzOILSKgJfHv/R0wm1nAVeLexX4wWxgo3rP5FyNEjbbE00tPmCBsK4l3Z5rBalgEVCUe3bsI ZvMK2EvMmNIKVi8kkCpx9eUDsF2cAk4SO2/fB7MZga77fmoNE8QucYlbT+YzQVwtILFkz3lm CFtU4uXjf1DfKEmsPbydBaJeT+LG1ClsELa1xJGbV6FsbYllC19D3SAocXLmE5YJjOKzkKyY haR9FpL2WUjaZyFpX8DIuopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMAoPbvltsIPx5XPH Q4wCHIxKPLwL9qwMFmJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjBG2vdVBvhUZDKdPdrE+s5x/8vfO6vIj0/P05+4+WmAvcUXv6i7fZ/VSfCmCTNrrJLkE j1y22CnFwWZyyWCC2tnjT2d0HyhwzX8zRYBri4SXMpPQayHD+Wvd8ozyt9zQKZIR2+dpJN/x nOGvZbIy128PDZ77Xp1Tv78KeTdrno32v7CD097NVmIpzkg01GIuKk4EAIVYUgyjAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/783jU6xBlue4WNYmG16oUJZz5Gw Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] SCTP NAPT/NAT Support 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, 25 Jun 2014 05:40:25 -0000 combining them in one document it make perfect sense=20 br Sal On Jun 24, 2014, at 5:16 PM, Michael Tuexen wrote: > On 24 Jun 2014, at 14:10, Gorry Fairhurst wrote: >=20 >>=20 >> Last IETF tsvwg discussed the possibility of merging two milestones in T= SVWG relating to SCTP and NAPT/NAT, to result in a single document on this = topic. >>=20 >> The current milestones are: >> * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as PS >> * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP >>=20 >> I hope that whatever way this proceeds, we suggest the document(s) clear= ly identify the parts that relate to: >> (1) implementing a NAT/NAPT >> and (2) the support needed for SCTP implementors/users use a NAPT >>=20 >> As I recall, there was little opposition to this restructuring of the wo= rk, and this email is to make the list aware of this proposal. >> Please send comments if any to the list, this will help the Chairs make = a decision on how best to proceed. > I think it really makes sense to combine them into a single document. >=20 > Best regards > Michael >>=20 >> Best wishes, >>=20 >> Gorry, David and James >> (tsvwg Co-Chairs) >>=20 >>=20 >>=20 >=20 From nobody Wed Jun 25 01:33:39 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 AFA0E1B2B0F for ; Wed, 25 Jun 2014 01:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 gbEy6eH4uw_D for ; Wed, 25 Jun 2014 01:33:36 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A167D1B2ADD for ; Wed, 25 Jun 2014 01:33:35 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so2018887wiw.17 for ; Wed, 25 Jun 2014 01:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=K6ZhUNVk8VZx3yh5rIJhn/J5T4scZQXRWlZZf2V6RcA=; b=C1Y1qaSPoFLcDOgvrJJzXhf/ZDoq4CN8c4SWSwx/OA1jqEivPZj8nxd169sW8qRQEx enw9/jXhtiMTlHjY2Vx8CENd0MUK3Wo9hLRnuL+FwAnINjYYdEiiIe18XTPnJ6wZPQmn AzTqAqO7LQXpN2kiyGnC+kUFnV0R+KBEh+3nw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=K6ZhUNVk8VZx3yh5rIJhn/J5T4scZQXRWlZZf2V6RcA=; b=e7Z9p98NZ/f3CHAKPsSg4Th1cI52DtL8Ln0uOHOONtKT+JlEP+1D6P64KwPSD0+/w9 277mDmUD3OiVlmiNsvWA6lYW4g2gX5nb4dw1Q1BynUVFlxKYCnhdxx+uxIVOW3sLxbe5 Nh46zAnzecW5zKEyDRD9xbCIQOB32P7/Dbej/xEbE05txCb7OuqKSi7FzGsCV9yNl7/z fMeBm4WxDm6NW87YtGvSQFUz/7fb3tq0LaU1iPBIt7f/YheVgeI9rPgVwNLN5ZGHOOOC cPkv6y/SgnbfiqP8vG0O9aHVrNGs4E4AYK+m+ePsOuq+TFXlb2dku+666MW4Pda6luni 99Ng== X-Gm-Message-State: ALoCoQlvbLr/TldUMC38ZbMgOoi3nSKlIIJ/tglESmYLzz1CXkmA30QekWkYVgCKfOmA+VMJM0kakziXh1Cj2CROkX7vYSHTQQ== X-Received: by 10.194.90.77 with SMTP id bu13mr8097786wjb.92.1403685212954; Wed, 25 Jun 2014 01:33:32 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <53A96AB0.9080507@erg.abdn.ac.uk> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQYStMsTadSW14P5GCCXMnCRcmuAI/UnpeAu0EB3+bVna5gA== Date: Wed, 25 Jun 2014 10:32:52 +0200 Message-ID: <106a5ad883769e9940a1e7bc1d5d3cfe@mail.gmail.com> To: Michael Tuexen , Randall Stewart Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/YM8lyWv-rbf-9UVUJwaL5hQcOXI Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] SCTP NAPT/NAT Support 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, 25 Jun 2014 08:33:37 -0000 Hi, I fully support to merge the two documents. The split has always been very problematic and I believe that we all are served best by merging the documents. I would go so far as to say that even if one split them now one would eventually want to join them later on. NAT Traversal of SCTP is an important issue for SCTP deployment. The complexity of the solutions differs substantially as to whether SCTP is SH or MH. I believe that a join of the documents serve best to specify the functions in a consistent and comprehensive manner. I would hope that such clear specification could help progress NAT traversal support in the network. Possibly with the more simple SH SCTPNAT functions support being provided more rapidly than MH SCTP support. BR, Karen > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Tuexen > Sent: 24. juni 2014 18:48 > To: Randall Stewart > Cc: Gorry Fairhurst; tsvwg WG > Subject: Re: [tsvwg] SCTP NAPT/NAT Support > > > On 24 Jun 2014, at 18:05, Randall Stewart > wrote: > > > Gorry: > > > > I really do agree that this makes complete sense. The document was > > originally one and for some unknown reason (I don't remember) we split > I think the reason was that the NAT stuff was requested to be handled in > BEHAVE as an informational document, but we needed to protocol > mechanisms in a standards track document which was thought to be better > handled in TSVWG. > Since we deal now with the documents in a single WG, we can merge them. > > Best regards > Michael > > it into two. This makes reading it very difficult, if you start > > reading one often you must get the other out and read that in > > combination if you want it to make much sense.. > > > > Putting them together makes things *much* easier and more clear :-) > > > > R > > On Jun 24, 2014, at 8:10 AM, Gorry Fairhurst > wrote: > > > >> > >> Last IETF tsvwg discussed the possibility of merging two milestones in > TSVWG relating to SCTP and NAPT/NAT, to result in a single document on this > topic. > >> > >> The current milestones are: > >> * Nov 2014 - Submit 'SCTP NAT Support' to IESG for consideration as > >> PS > >> * Nov 2014 - Submit 'SCTP NAT Specification' as a BCP > >> > >> I hope that whatever way this proceeds, we suggest the document(s) > clearly identify the parts that relate to: > >> (1) implementing a NAT/NAPT > >> and (2) the support needed for SCTP implementors/users use a NAPT > >> > >> As I recall, there was little opposition to this restructuring of the work, and > this email is to make the list aware of this proposal. > >> Please send comments if any to the list, this will help the Chairs make a > decision on how best to proceed. > >> > >> Best wishes, > >> > >> Gorry, David and James > >> (tsvwg Co-Chairs) > >> > >> > > > > ----- > > Randall R. Stewart > > rstewart@adaranetworks.com > > > > > > > > From nobody Wed Jun 25 02:02:34 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 028D91B2B23 for ; Wed, 25 Jun 2014 02:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVC3NwJg9y67 for ; Wed, 25 Jun 2014 02:02:30 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c: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 30EBA1B2B17 for ; Wed, 25 Jun 2014 02:02:30 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so1658907wes.23 for ; Wed, 25 Jun 2014 02:02:28 -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; bh=9YvE5tKNtzJEFMZRGJknXKuVsu9LSt/KlmHRZrDOPNg=; b=IaETJAfXHg29JsdQARKKG74uhFgQHLonS0WSx75Q6pWmtXafD3EGJnknXm3fCVx1D7 omDeLcLay9sQdwCGVKrjobQcVn58aKQkoaD7M8Fh2emSo2NrOOddvPQiVUKLbQr/m5du P2+3/HsiSq6dSoQ5ovFnBWLZAn4Vnx0xYHfVs= 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; bh=9YvE5tKNtzJEFMZRGJknXKuVsu9LSt/KlmHRZrDOPNg=; b=PBcJgx0n7PuYoSaA5GRRcXztcHOIqG/QKWjcKlBg+mtwxNc2Qjpg4OqrFpOpT1TPuW lu2rre84PBfg4Ce1YwNbBc/oTX75rHEnEOi+ps5B19mnfgUUzExVZVaRqt5GSISH7NuP 0Xpn2v8lQqUpIQvvosuRXmgVMwi5+D6bAfF/j50tnDD3aPyHCuBqNSVQaMCrn1Wtn6hk 0pFohab0FRBG9in7qbE/ZXXFJmiYdbdD4sqWlcQXVbZg3S31hAr0nIvUgJiV4EiEEYej 7rMwigCleXOVU9gw//fhxgjVFiWTNzWI2crDryUU63mcdz8KK8tTHjYAaPI7JaXwVySo lOTQ== X-Gm-Message-State: ALoCoQk0F1f5GLJK0M7PCj+ylwbI+NDrspDAd5EAhRqqjvHO4kbtkUinODzjqmETDmxb3FACqeTfny9JYa0BZ0qypoBbM9z+qw== X-Received: by 10.180.77.17 with SMTP id o17mr8125616wiw.31.1403686948795; Wed, 25 Jun 2014 02:02:28 -0700 (PDT) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+QVDA3KcKoIo6/T+2QiYJ1zS1/Og== Date: Wed, 25 Jun 2014 11:02:27 +0200 Message-ID: <2f8d59e54cf63bfce71e3d945afc9512@mail.gmail.com> To: gorry@erg.abdn.ac.uk, James Polk Content-Type: multipart/alternative; boundary=f46d043c7b34f5881c04fca555e2 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/BH5q9H16vLklEoObs1mSDPCDHlE Cc: tsvwg@ietf.org Subject: [tsvwg] tsvwg slot for pres on advances on SCTP Tail Loss Recovery ? 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, 25 Jun 2014 09:02:32 -0000 --f46d043c7b34f5881c04fca555e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We are working with some advances on SCTP Loss Recovery in order to more efficiently support loss recovery. We are wondering if there would be a 5-10 minutes slot available at the IETF 90 tsvwg session to present our work. The advances consist of the advancement of SCTP Fast Recovery with some =E2=80=9CSCTP-equivalent=E2=80=9D additions from RFC6675 (TCP) plus the addition of a timer driven state machine for proactive entering of Fast Recovery, not identical to, but very significantly inspired by the ideas from the TLP approach presented for TCP by Google at IETF87. We are in the early phase of the work (spec, implementation, tests) and have not yet prepared a draft. Such would be available only for IETF91. BR, Karen ***************************************************************************= **************** *Karen Egede Nielsen* Software Architect, Ph.D. *Ericsson, * Kistav=C3=A4gen 25, 164 80 Stockholm, SWEDEN Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com www.ericsson.com ***************************************************************************= ************** --f46d043c7b34f5881c04fca555e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

=C2=A0

We are working with some advances on SCTP = Loss Recovery in order to more efficiently support

loss recovery. We are wondering= if there would be a 5-10 minutes slot available at the IETF 90 tsvwg sessi= on to present

our wo= rk.

=C2=A0

The advances consist of the advancement of SC= TP Fast Recovery with some =E2=80=9CSCTP-equivalent=E2=80=9D additions from= RFC6675 (TCP)

plus the addition of a timer dr= iven state machine for proactive entering of Fast Recovery, not identical t= o, but very significantly

inspired by the ideas from the TLP approach presented for TCP by Goog= le at IETF87.

=C2=A0

We are in the early phase of the work (spec, = implementation, tests) and have not yet prepared a draft.

Such would be available only for IETF91.

=C2=A0

BR, Karen

=C2=A0

=C2=A0

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

= Karen Egede Nielsen

Software Architect, Ph.D.

=C2=A0

= Ericsson,

Kistav=C3=A4gen= 25,

164 80 Stockholm, SWEDEN

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

www.ericsson.com

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

=C2=A0

=C2=A0

--f46d043c7b34f5881c04fca555e2-- From nobody Wed Jun 25 02:08:23 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 967511B2B23 for ; Wed, 25 Jun 2014 02:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 iC-Bb-0w1awU for ; Wed, 25 Jun 2014 02:08:16 -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 E8D0F1B2AB1 for ; Wed, 25 Jun 2014 02:08:15 -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 220C42B40E1; Wed, 25 Jun 2014 10:08:15 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 25 Jun 2014 10:08:15 +0100 Message-ID: In-Reply-To: <2f8d59e54cf63bfce71e3d945afc9512@mail.gmail.com> References: <2f8d59e54cf63bfce71e3d945afc9512@mail.gmail.com> Date: Wed, 25 Jun 2014 10:08:15 +0100 From: gorry@erg.abdn.ac.uk To: "Karen E. Egede Nielsen" 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/lvNmeyNJ3F73aQG8rhy6BQ14H5I Cc: gorry@erg.abdn.ac.uk, James Polk , tsvwg@ietf.org Subject: Re: [tsvwg] tsvwg slot for pres on advances on SCTP Tail Loss Recovery ? 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, 25 Jun 2014 09:08:18 -0000 Hi, The topic appears to fall within tsvwg: To answer the agenda question, I'd like to know more: What sort of presentation are you thinking about? - will you have a draft (even just outline of scope) published by then? Will you be presenting data or mechanism proposals? Gorry > Hi, > > > > We are working with some advances on SCTP Loss Recovery in order to more > efficiently support > > loss recovery. We are wondering if there would be a 5-10 minutes slot > available at the IETF 90 tsvwg session to present > > our work. > > > > The advances consist of the advancement of SCTP Fast Recovery with some > “SCTP-equivalent” additions from RFC6675 (TCP) > > plus the addition of a timer driven state machine for proactive entering > of > Fast Recovery, not identical to, but very significantly > > inspired by the ideas from the TLP approach presented for TCP by Google at > IETF87. > > > > We are in the early phase of the work (spec, implementation, tests) and > have not yet prepared a draft. > > Such would be available only for IETF91. > > > > BR, Karen > > > > > > ******************************************************************************************* > > *Karen Egede Nielsen* > > Software Architect, Ph.D. > > > > *Ericsson, * > > Kistavägen 25, > > 164 80 Stockholm, SWEDEN > > Direct Phone / Mobile +45 25134336 > > E-mail: karen.nielsen@tieto.com > > www.ericsson.com > > ***************************************************************************************** > From nobody Wed Jun 25 02:32: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 762041B2B26 for ; Wed, 25 Jun 2014 02:32:00 -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 BMZ7zhqtE5ne for ; Wed, 25 Jun 2014 02:31:59 -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 B7C121B2B18 for ; Wed, 25 Jun 2014 02:31:58 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so1735288wgg.32 for ; Wed, 25 Jun 2014 02:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xvgzLaja1MG50aYZYwSVja7Eu+uWq9KvD1yl+istkjs=; b=VjicjxTOkz4AyAjM/0ywNEn4nQxG/33iBcHZoTJDCvBxI4DxR3nM5ywnXrI5O7AEO2 j0BLzTAv16SrEXD2g1o7LIRDqgEFYdZMLYi0tU40MXo7Lx6FWCRhx30XOcdntCYgXYS2 VFyDtjyTdpxxFfPv+CVMX9pv+wDlcssC8RyrA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xvgzLaja1MG50aYZYwSVja7Eu+uWq9KvD1yl+istkjs=; b=U+NPbSXSF6E+fMB0HdVr1F+cum5iLrBqaBONzzBygFhB/F3MUIoD9Ak8721F4wL3Ka OAszV4PhPcuqPo6ObURYrxCOLt6Tgw1cjmRuQUKHSTm+bR0ejoO5bLyDO5vgZaALgs+Z CxTFepu0vc3INCb1sDUR4mNOB24NJnara6slqXwwd5S16TYWn1+qZC6IA0zwpOaVjtOk ap8Aga9qxMJCmL8BbPUDBrrc3xcArMsqRhzwDAfld5JhVAM6AtFCKKyknVS0kUqhsLWW kGiVjzetAEbYNF7mZabq9pUu/dHitNB1WCbFR52X6KaRqlxn5CN/pGprUkErUJ3xyUN0 IsRQ== X-Gm-Message-State: ALoCoQlDVSy+hdEE8g59sgRVAX1aUeQFph/vxypmoKu4CLTD/kjShdghmIJRIG+imwD1lN6HEZVYz46Qg/npvNpwPvv6f2qX0Q== X-Received: by 10.180.149.240 with SMTP id ud16mr9001249wib.3.1403688717334; Wed, 25 Jun 2014 02:31:57 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <2f8d59e54cf63bfce71e3d945afc9512@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQECj/fkZdwThWMFX1hp418o8Z37FAGOHc26nQ8ZeGA= Date: Wed, 25 Jun 2014 11:31:56 +0200 Message-ID: <95883cba58c7ebee8aaf255c7f58c402@mail.gmail.com> To: gorry@erg.abdn.ac.uk 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/0_Rotdqg-0KaWX4zAoY_tyjhxkI Cc: James Polk , tsvwg@ietf.org Subject: Re: [tsvwg] tsvwg slot for pres on advances on SCTP Tail Loss Recovery ? 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, 25 Jun 2014 09:32:00 -0000 Hi, We will not have a draft available nor published for IETF90. We would present the algorithm extensions worked with and some limited functional tests results only. The functional test results would not be qualified by traffic tests but would relate only to the functional operation of the algorithm and the achieved benefits in terms of the latency of an individual loss recovery episode. The work clearly is work in progress and work on this will continue still for some time in all aspects; refinement of algorithm (CC issues in particular), implementation and collection of data from traffic tests experiments. The purpose of the presentation would be to collect input and guidance from the working group - both in terms of the interest of the working group in this work as well as in terms of technical guidance on the validity of the approach. There also is synergy (or lack of) with tcmp work to consider. BR, Karen > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: 25. juni 2014 11:08 > To: Karen E. Egede Nielsen > Cc: gorry@erg.abdn.ac.uk; James Polk; tsvwg@ietf.org > Subject: Re: tsvwg slot for pres on advances on SCTP Tail Loss Recovery ? > > Hi, > > The topic appears to fall within tsvwg: To answer the agenda question, I'= d > like > to know more: > > What sort of presentation are you thinking about? - will you have a draft > (even just outline of scope) published by then? Will you be presenting > data > or mechanism proposals? > > Gorry > > > > Hi, > > > > > > > > We are working with some advances on SCTP Loss Recovery in order to > > more efficiently support > > > > loss recovery. We are wondering if there would be a 5-10 minutes slot > > available at the IETF 90 tsvwg session to present > > > > our work. > > > > > > > > The advances consist of the advancement of SCTP Fast Recovery with > > some =C3=A2=E2=82=AC=C5=93SCTP-equivalent=C3=A2=E2=82=AC=C2=9D addition= s from RFC6675 (TCP) > > > > plus the addition of a timer driven state machine for proactive > > entering of Fast Recovery, not identical to, but very significantly > > > > inspired by the ideas from the TLP approach presented for TCP by > > Google at IETF87. > > > > > > > > We are in the early phase of the work (spec, implementation, tests) > > and have not yet prepared a draft. > > > > Such would be available only for IETF91. > > > > > > > > BR, Karen > > > > > > > > > > > > > ********************************************************** > ************ > > ********************* > > > > *Karen Egede Nielsen* > > > > Software Architect, Ph.D. > > > > > > > > *Ericsson, * > > > > Kistav=C3=83=C2=A4gen 25, > > > > 164 80 Stockholm, SWEDEN > > > > Direct Phone / Mobile +45 25134336 > > > > E-mail: karen.nielsen@tieto.com > > > > www.ericsson.com > > > > > ********************************************************** > ************ > > ******************* > > > From nobody Wed Jun 25 06:24: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 630F51B2C70; Wed, 25 Jun 2014 06:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zO-VEjL2XdDs; Wed, 25 Jun 2014 06:24: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 A088B1B2BE7; Wed, 25 Jun 2014 06:23:59 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 901CF2B44D5; Wed, 25 Jun 2014 14:23:58 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 411952B40E1; Wed, 25 Jun 2014 14:23:57 +0100 (BST) Message-ID: <53AACD6C.3010309@erg.abdn.ac.uk> Date: Wed, 25 Jun 2014 14:23:56 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dart@ietf.org, tsvwg WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/CtFr92rj30H-I6NNQtsTuLwNoiE Subject: Re: [tsvwg] [Dart] Comments on draft-ietf-tsvwg-rtcweb-qos-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 13:24:02 -0000 A few comments in-line, following on... > Hi Subha, > > thanks for you reply, see comments inline: > >> An authorization mechanism alone is probably not sufficient, because >> DS boundary nodes may need to police (e.g., remark/drop) incoming >> traffic according to some agreed/negotiated traffic profile for some >> of the PHBs, e.g., the EF PHB does not work properly if its traffic >> class is overloaded (see below). >> >> SD: Agreed. The previous line states: " Therefore, the DSCP value >> may be remarked at the network edge through policy to any other DSCP >> value, including best effort.". There is already a mention that >> apckers may be remarked or dropped and any additional mitigation is >> outside the scope of this draft. > > Unfortunately, this doesn't address my comment. DSCP remarking by > provider policy is somewhat different from having policers installed > (e.g., a token bucket w/ marker and dropper) that perform traffic > conditioning according to some installed traffic profile. Static > remarking of DSCPs may be caused by using a different DCSP/PHB mapping > or lack of DiffServ support etc. which is slightly different. > +1 I think if the draft recommends admission-controlled PHBs then the draft needs to be clear that these particular flows may not be carried over the path (in addition to could be remarked to another PHB), which may require sort of fall-back mechanism (that's probably easy to realise). In addition though, these PHBs can (and seem likely to be) policed to a conformant rate. That will result in some form of loss (or remark), which suggests a congestion response (if the traffic is actually elastic), otherwise cease? >> The problem with using EF is that if too many EF marked packets are >> injected into a DS domain, they probably void the EF properties for >> other users within this domain (background is that the service rate of >> EF packets on a given output interface must exceed their arrival rate at >> that interface over long and short time intervals - this is usually >> checked by admission control before use and policing at DS boundary >> nodes during use). Therefore, maybe some discussion w.r.t. RFC5865 >> http://tools.ietf.org/html/rfc5865 may be useful. >> SD: Agreed that admission control is very useful and relevant. This >> draft is intended for the selection and use of the right DSCP for >> webrtc media flows. There is a mention of over-subscription in the >> beginning. > Sure, however, my point was that simply injecting traffic marked with > a DSCP for a PHB that normally requires prior admission control is > somewhat problematic: either guarantees for already admitted flows > are violated or such traffic has to be dropped. I see a potential problem here, if this becomes a default: If widely deployed using EF, the traffic will likely result in this DSCP being ignored/dropped (not given you EF properties0)or in breaking EF properties for other flows (which needs to be policed). >> If a packet enters a QoS domain that has no support for the above >> defined Data Types/Application (service) classes, then the network >> node at the edge will remark the DSCP value based on policies. >> >> Yes, but even if there is support for these classes traffic >> conditioning (e.g., remarking/dropping etc.) may be necessary and >> applied. Remarking to different PHBs may also lead to packet >> reordering within a media flow?! > >> SD: Remarking/dropping may occur, which is mentioned in the draft. > Same issue as above: remarking caused by a static DS domain policy > (PHBx -> PHBy) is different from remarking and other actions that > boundary nodes may perform for individual flows according to > traffic profiles. > > Regards, > Roland > In short... there are different pathologies (per packet conditioning action) when you send packets using EF, for traffic that the network provider didn't provision. This is a different behavior to remarking because the DSCP or PHB was not supported at a boundary. Gorry From nobody Wed Jun 25 16:27: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 C75D61A02EB; Wed, 25 Jun 2014 16:27:24 -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 8Scw2sh1wJFN; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5AB1A0291; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so2215051pdj.8 for ; Wed, 25 Jun 2014 16:27:23 -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=dIP8mwMt8T+GJhCTvdsJyY4Y/+N2w6IbYv5dJlC/f+M=; b=IulVlSLgfZZRVeU/rL+28yf47gbyqIHkKVD04ZtdUV22wZe9ruhXqU/aWQbJOsFTN7 PKgrOmVdNlT1JSYov48BNsZA7aCgx54ajXVwhu7ot93G6VoO6lSf2ZVhDtojnvAkXyrT cvPHm2TPct0I2Zrb4FQcuIsQCn7t6eI94pP/XxeuV7Gc9IMfP3S89TWfGNFdwDVG604B Tz6nMkUwMYgkLFwHlsRIoVz8/yinACwofdCuR/U8rFW41D+iQZdik8SuDhZeCAzuI8cG jrJAijTRjoda/h+T9i+2+iPO3AA6pYaXnyPqYw23BMiemp6PpUdERpPNSZVowIcr9axo j0fA== X-Received: by 10.69.17.66 with SMTP id gc2mr16120057pbd.90.1403738843269; Wed, 25 Jun 2014 16:27:23 -0700 (PDT) Received: from [192.168.178.23] (153.199.69.111.dynamic.snap.net.nz. [111.69.199.153]) by mx.google.com with ESMTPSA id qk9sm24937114pac.16.2014.06.25.16.27.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 16:27:22 -0700 (PDT) Message-ID: <53AB5AE1.9040306@gmail.com> Date: Thu, 26 Jun 2014 11:27:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <53AACD6C.3010309@erg.abdn.ac.uk> In-Reply-To: <53AACD6C.3010309@erg.abdn.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/VJJsM8ochcQPIAojuBZZoQvYVFA Cc: dart@ietf.org, tsvwg WG Subject: Re: [tsvwg] [Dart] Comments on draft-ietf-tsvwg-rtcweb-qos-00 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, 25 Jun 2014 23:27:24 -0000 On 26/06/2014 01:23, Gorry Fairhurst wrote: ... >> Sure, however, my point was that simply injecting traffic marked with >> a DSCP for a PHB that normally requires prior admission control is >> somewhat problematic: either guarantees for already admitted flows >> are violated or such traffic has to be dropped. > > I see a potential problem here, if this becomes a default: If widely > deployed using EF, the traffic will likely result in this DSCP being > ignored/dropped (not given you EF properties0)or in breaking EF > properties for other flows (which needs to be policed). If you look at RFC3246 (the EF specification) you will find these words: the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval, independent of the offered load of non-EF traffic to that interface. In other words, if you do not apply admission control to EF traffic, excess traffic *will* be discarded, because EF has a strict maximum rate. Brian From nobody Thu Jun 26 04:46: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 B6F881B2B48; Thu, 26 Jun 2014 04:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 QzGlZxOe6vLX; Thu, 26 Jun 2014 04:45: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 0C3C21B2B47; Thu, 26 Jun 2014 04:45:46 -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 DD8442B40E9; Thu, 26 Jun 2014 12:45:44 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 26 Jun 2014 12:45:45 +0100 Message-ID: In-Reply-To: <53AB5AE1.9040306@gmail.com> References: <53AACD6C.3010309@erg.abdn.ac.uk> <53AB5AE1.9040306@gmail.com> Date: Thu, 26 Jun 2014 12:45:45 +0100 From: gorry@erg.abdn.ac.uk To: "Brian E Carpenter" 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/m8JydPbD1mY3oITd4c3Evaj3d28 Cc: gorry@erg.abdn.ac.uk, dart@ietf.org, tsvwg WG Subject: Re: [tsvwg] [Dart] Comments on draft-ietf-tsvwg-rtcweb-qos-00 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, 26 Jun 2014 11:45:47 -0000 > On 26/06/2014 01:23, Gorry Fairhurst wrote: > ... >>> Sure, however, my point was that simply injecting traffic marked with >>> a DSCP for a PHB that normally requires prior admission control is >>> somewhat problematic: either guarantees for already admitted flows >>> are violated or such traffic has to be dropped. >> >> I see a potential problem here, if this becomes a default: If widely >> deployed using EF, the traffic will likely result in this DSCP being >> ignored/dropped (not given you EF properties0)or in breaking EF >> properties for other flows (which needs to be policed). > > If you look at RFC3246 (the EF specification) you will find > these words: > > the rate at which EF > traffic is served at a given output interface should be at least the > configured rate R, over a suitably defined interval, independent of > the offered load of non-EF traffic to that interface. > > In other words, if you do not apply admission control to > EF traffic, excess traffic *will* be discarded, because EF > has a strict maximum rate. > > Brian > Right - so EF is a useful service for many things - but my comment related to whether widely-deployed web apps should be recommending a default EF DSCP for their critical traffic? Gorry From nobody Fri Jun 27 19:16: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 04AED1A026F for ; Fri, 27 Jun 2014 19:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.856 X-Spam-Level: **** X-Spam-Status: No, score=4.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=1.012, RDNS_NONE=0.793, 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 CPSKWrIUuJgu for ; Fri, 27 Jun 2014 19:16:42 -0700 (PDT) Received: from mail.bit.edu.cn (unknown [202.204.80.7]) by ietfa.amsl.com (Postfix) with SMTP id D06D91A026A for ; Fri, 27 Jun 2014 19:16:41 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 202.204.94.84 X-EMDG-VER: 4.1.1 X-EMDG-ABROAD: no Received: (eyou anti_spam gateway 4.1.0); Sat, 28 Jun 2014 10:15:47 +0800 X-EMDG-MID: <603921747.04891@mail.bit.edu.cn> Received: from 202.204.94.84 by 202.204.80.84 with SMTP; Sat, 28 Jun 2014 10:15:47 +0800 Received: from localhost ([127.0.0.1]) by bit.edu.cn with sendmail id 152fca850dfe805c1ecae1e590c62015; Sat, 28 Jun 2014 10:18:06 +0800 Date: Sat, 28 Jun 2014 10:18:06 +0800 From: "=?GBK?B?tcvP/sHV?=" To: "tsvwg" Message-Id: <140628101806661095008435@bit.edu.cn> MIME-Version: 1.0 X-Mailer: eYou WebMail 8.1.0.4 X-Eyou-Client: 10.15.10.47 X-Content_type: html Content-Type: multipart/alternative; boundary="7240b7768e17b2ddc20908701693ad92" Content-Transfer-Encoding: 7bit X-Eyou-Sender: Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/X8O8q0GznqAOBRVa8_WT1nhAcZo Subject: [tsvwg] =?gbk?q?FW=A3=BANew_Version_Notification_for_draft-deng-t?= =?gbk?q?svwg-qoe-evaluation-has-01=2Etxt?= 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, 28 Jun 2014 02:16:48 -0000 --7240b7768e17b2ddc20908701693ad92 Content-Type: text/plain; charset="GBK" Content-Transfer-Encoding: base64 SGksIGFsbAoKVGhpcyBhIG5ldyB2ZXJzaW9uIG9mICBkcmFmdC1kZW5nLXRzdndnLXFv ZS1ldmFsdWF0aW9uLWhhcy0wMS50eHQsIGFuZCB3ZWxjb21lcyB5b3VyIHJldmlldyBh bmQgY29tbWVudHMuCiAKVGhhbmtzLFhpYW9saW4gRGVuZwoKLS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZyb206ICJJRVRGIEktRCBTdWJtaXNzaW9u IFRvb2wiIDxpZHN1Ym1pc3Npb25AaWV0Zi5vcmc+CkRhdGU6IDIwMTQvMDYvMjgKU3Vi amVjdDogQ29uZmlybSBzdWJtaXNzaW9uIG9mIEktRCBkcmFmdC1kZW5nLXRzdndnLXFv ZS1ldmFsdWF0aW9uLWhhcwpUbzogIlhpYW9saW4gRGVuZyIgPHhpYW9saW5kZW5nQGJp dC5lZHUuY24+LCAiR3VhbmdsaW4gSGFuIiA8aGFuZ3VhbmdsaW5AaHVhd2VpLmNvbT4K CgoKCkhpLAoKCgpUaGUgSUVURiBkYXRhdHJhY2tlciBkcmFmdCBzdWJtaXNzaW9uIHNl cnZpY2UgaGFzIHJlY2VpdmVkIHlvdXIgZHJhZnQKCmRyYWZ0LWRlbmctdHN2d2ctcW9l LWV2YWx1YXRpb24taGFzLTAxLCBhbmQgcmVxdWlyZXMgYQoKY29uZmlybWF0aW9uIHN0 ZXAgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBjb21wbGV0ZSB0aGUgcG9zdGluZyBvZgoK dGhlIGRyYWZ0LgoKCgpQbGVhc2UgZm9sbG93IHRoaXMgbGluayB0byB0aGUgcGFnZSB3 aGVyZSB5b3UgY2FuIGNvbmZpcm0gdGhlIHBvc3Rpbmc6CgoKCmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9zdWJtaXQvc3RhdHVzLzYwODMxL2NvbmZpcm0vY2NhODRlNTk4 NDJjOWMxOGRhYjg1NmRlYTAzODFhN2YvCgoKCgoKQmVzdCByZWdhcmRzLAoKCgpUaGUg SUVURiBTZWNyZXRhcmlhdAoKdGhyb3VnaCB0aGUgZHJhZnQgc3VibWlzc2lvbiBzZXJ2 aWNlCgoKCgoKCiA= --7240b7768e17b2ddc20908701693ad92 Content-Type: text/html; charset="GBK" Content-Transfer-Encoding: base64 PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OsvOzOU7Ij5IaSwgYWxsPGJyIC8+CjxiciAv PgpUaGlzIGEgbmV3IHZlcnNpb24gb2YmbmJzcDsmbmJzcDtkcmFmdC1kZW5nLXRzdndn LXFvZS1ldmFsdWF0aW9uLWhhcy0wMS50eHQsJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDIxcHg7 Ij5hbmQgd2VsY29tZXMgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLjwvc3Bhbj48L3Nw YW4+PGJyIC8+CiZuYnNwOwo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNpbXN1bjsgZm9udC1zaXplOiAx NHB4OyBsaW5lLWhlaWdodDogMjFweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrL zszlOyI+PHNwYW4gbGFuZz0iRU4tVVMiIHhtbDpsYW5nPSJFTi1VUyI+VGhhbmtzLDwv c3Bhbj48L3NwYW4+PC9wPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6y87M5TsiPjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGxp bmUtaGVpZ2h0OiAyMXB4OyI+WGlhb2xpbiBEZW5nPC9zcGFuPjwvc3Bhbj48YnIgLz4K PGJyIC8+Ci0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxiciAv PgpGcm9tOiAmcXVvdDtJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wmcXVvdDsgJmx0O2lk c3VibWlzc2lvbkBpZXRmLm9yZyZndDs8YnIgLz4KRGF0ZTogMjAxNC8wNi8yODxiciAv PgpTdWJqZWN0OiBDb25maXJtIHN1Ym1pc3Npb24gb2YgSS1EIGRyYWZ0LWRlbmctdHN2 d2ctcW9lLWV2YWx1YXRpb24taGFzPGJyIC8+ClRvOiAmcXVvdDtYaWFvbGluIERlbmcm cXVvdDsgJmx0O3hpYW9saW5kZW5nQGJpdC5lZHUuY24mZ3Q7LCAmcXVvdDtHdWFuZ2xp biBIYW4mcXVvdDsgJmx0O2hhbmd1YW5nbGluQGh1YXdlaS5jb20mZ3Q7PGJyIC8+Cjxi ciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgpIaSw8YnIgLz4KPGJyIC8+CjxiciAvPgo8 YnIgLz4KVGhlIElFVEYgZGF0YXRyYWNrZXIgZHJhZnQgc3VibWlzc2lvbiBzZXJ2aWNl IGhhcyByZWNlaXZlZCB5b3VyIGRyYWZ0PGJyIC8+CjxiciAvPgpkcmFmdC1kZW5nLXRz dndnLXFvZS1ldmFsdWF0aW9uLWhhcy0wMSwgYW5kIHJlcXVpcmVzIGE8YnIgLz4KPGJy IC8+CmNvbmZpcm1hdGlvbiBzdGVwIGluIG9yZGVyIHRvIGJlIGFibGUgdG8gY29tcGxl dGUgdGhlIHBvc3Rpbmcgb2Y8YnIgLz4KPGJyIC8+CnRoZSBkcmFmdC48YnIgLz4KPGJy IC8+CjxiciAvPgo8YnIgLz4KUGxlYXNlIGZvbGxvdyB0aGlzIGxpbmsgdG8gdGhlIHBh Z2Ugd2hlcmUgeW91IGNhbiBjb25maXJtIHRoZSBwb3N0aW5nOjxiciAvPgo8YnIgLz4K PGJyIC8+CjxiciAvPgpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0L3N0 YXR1cy82MDgzMS9jb25maXJtL2NjYTg0ZTU5ODQyYzljMThkYWI4NTZkZWEwMzgxYTdm LzxiciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgo8YnIgLz4KPGJyIC8+CkJlc3QgcmVn YXJkcyw8YnIgLz4KPGJyIC8+CjxiciAvPgo8YnIgLz4KVGhlIElFVEYgU2VjcmV0YXJp YXQ8YnIgLz4KPGJyIC8+CnRocm91Z2ggdGhlIGRyYWZ0IHN1Ym1pc3Npb24gc2Vydmlj ZTxiciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgo8YnIgLz4KPGJyIC8+CjxiciAvPgom bmJzcDs= --7240b7768e17b2ddc20908701693ad92-- From nobody Mon Jun 30 22:38: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 924721A0164; Mon, 30 Jun 2014 22:37:58 -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 3LlrRnDtM7wa; Mon, 30 Jun 2014 22:37:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD591A0145; Mon, 30 Jun 2014 22:37:56 -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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701053756.27711.5517.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 22:37:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ibgWNBQhNuenuQTzxrx5RxANlbI Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-04.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: Tue, 01 Jul 2014 05:37:58 -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 : Quick Failover Algorithm in SCTP Authors : Yoshifumi Nishida Preethi Natarajan Armando Caro Paul D. Amer Karen E. E. Nielsen Filename : draft-ietf-tsvwg-sctp-failover-04.txt Pages : 17 Date : 2014-06-30 Abstract: One of the major advantages of SCTP is that it supports multi-homed communication. A multi-homed SCTP end-point has the ability to withstand network failures by migrating the traffic from an inactive network to an active one. However, if the [RFC4960] specified failover operation is followed there can be a significant delay in the migration to the active destination addresses, thus severely reducing the effectiveness of SCTP multi-homed operation. The memo complements RFC4960 by the introduction of the Potentially Failed state and associated new Quick Failover operation to apply during network failure and specifies for SCTP senders to support this more performance optimal failover procedure as an add-on to the [RFC4960] failover operation. The memo in addition updates [RFC4960] by clarifying a number of issues related to the path management operation during periods of partial or complete network failures. Finally the memo complements [RFC4960] by introduction of alternative switchover operation modes for the data transfer path management after a failover. These operation modes offer for more performance optimal operation in some network environments. From the perspective of this memo the implementation of the additional switchover operation modes is considered optional. The procedures defined require only minimal modifications to the current specification. The procedures are sender-side only and do not impact the SCTP receiver. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-failover-04 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/