From nobody Wed Mar 29 00:26:10 2017 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C46A12968F; Wed, 29 Mar 2017 00:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbtCcDDboyU5; Wed, 29 Mar 2017 00:26:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7957D128B4E; Wed, 29 Mar 2017 00:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Cc:From:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mbaxm6qX/RWhN04q2VeBjZCwkq0hGPdfc+ukib4DEE8=; b=NsiuoZ69YOOhfwBPQYk3gUzhJf HT/H8TgbaUpZx7hJNZFSqks4mBDhbMZG3juJMZW/jqrm2zYzkdoB2sWmbsVwBpCWWOmgHs/uw9lxR ZIzsuknfCOIA/Nn8ikEcidQU0MnwDfbq/BSJo08w2ElKOhT2s5jzqVYwW71B8YW5co/Zxe1ftCD2h RldJTNRkDykl6sIXtH6u2R/mP+Q1g1l7EaI5aIQ/7mzBxAgKpok8JvK9rTCa2xB2FEqg8qwto3tuW SQNOESvCAgRjiVmuvsmdlRn7OZcCYdQUSNbt5xXzo0x0YtZyHXW/eW8yZ3uiV+33W4ucflMhF+EHa bAtrdrpg==; Received: from [77.40.143.110] (port=55824 helo=[172.31.98.93]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ct7zX-0003Q6-8t; Wed, 29 Mar 2017 08:26:03 +0100 To: Dave Dolson References: <20160722110102.5697618.36413.99476@sandvine.com> From: Bob Briscoe Cc: TCP Prague List , tsvwg IETF list Message-ID: <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> Date: Wed, 29 Mar 2017 08:26:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20160722110102.5697618.36413.99476@sandvine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 07:26:08 -0000 Dave, I've cc'd this to tsvwg. We will put text in the ecn-l4s-id draft unless there is not consensus from others about this yet. I agree with Koen now. To be clear, I believe that a classic AQM supporting only RFC3168 (Classic) ECN: * should never alter the ECT(1) field * should be configurable between the following two behaviours: - [default] treat ECT(1) as if it does not support ECN, so drop where it would have marked CE - treat ECT(1) as if it is ECT(0) I am less keen than Koen on adding the latter option - I prefer clear simple advice to avoid confusion. So IMO, if you don't want another config knob, it would be OK to just support the default. Ideally, once the DualQ specs are approved, the AQM should also be upgraded to support Dual Qs and the squared relationship between them. Sorry it's taken so long to confirm this. Cheers Bob On 22/07/16 12:01, Dave Dolson wrote: > If an operator were to deploy ECN today, pre L4S, what should be the treatment of ECT(1)? > > I believe, from a discussion with Koen, that the safest approach is for a pre-L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) were treated the same as ECT(0) then new experimental TCP-Prague flows would out-compete any ECT(0) traffic. > > Is this agreed? If so, should it be recommended somewhere? > > Note that I got mixed answers on this from other IETF folks, so I think it is worth sorting out. > > > -Dave > > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Mar 29 07:41:00 2017 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D051242EA; Wed, 29 Mar 2017 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imHc6URK8OBZ; Wed, 29 Mar 2017 07:40:51 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F29B8127599; Wed, 29 Mar 2017 07:40:50 -0700 (PDT) X-AuditID: c1b4fb30-7db199800000628e-01-58dbc77017f3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 5A.45.25230.077CBD85; Wed, 29 Mar 2017 16:40:49 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 29 Mar 2017 16:40:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nuG2gI7wVUeGmZDqfYcgbmaL/EsCKYk62NuT3wQlTn8=; b=Zb5mpInRbZeu3Nfzco2c6fOVIfl6FDNFoAvdcWtsS5ZhJJ75jSgY+bs5XUffDZ6p0yLEo4OOEQUa5S0a8akxPYfLHuIn7cVxPpUS+HK9FYL93FnTvHl7fWCcu04Z1MFFxkc3inLU2yIWrCx2P334Y98b/bfqZrs2udRsV29O3bE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 14:40:16 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 14:40:15 +0000 From: Ingemar Johansson S To: tsvwg IETF list , "'tcpprague@ietf.org'" CC: Ingemar Johansson S Thread-Topic: 3GPP RAN2 : On TCP-specific improvements in the RAN Thread-Index: AdKomZzG9owUdRY+R4GVnm5sf8r/Tg== Date: Wed, 29 Mar 2017 14:40:15 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.93] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:8L8I7y6FrJqX3obtPp+gF+mMmBkqsbMmE3GNXZ/C6CclNg7eM1Tz/gukqlGMF6GtEdWhekTFa+F4pOw/vxzyd3hF+OzLFO14a2vok2PXued2EM5T3TYyFIxMJxBchnMwjIBwWFMQPq812UOmUbpEYfUKtXul5KtSlssxnbIjT7qz64St4/SLLYfGI331cPmPtA5RSswx2WcVFrn+qdygnYjCZe/Icj6DkuMyQIx1C/U5hCIRTodhxkJ4m/lIyjFpKe3MeyN3NJBNC80Z7mtlW8K2PXaQ/t5wRuzInkyJy+jBvmU6FsLB7LlSESF5wIR5N/3NEup7UADhj1c2Ju4PqA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(7736002)(74316002)(6436002)(38730400002)(7906003)(107886003)(33656002)(966004)(189998001)(3280700002)(66066001)(2900100001)(7696004)(3660700001)(5660300001)(8558605004)(54356999)(790700001)(6116002)(102836003)(99286003)(450100002)(2906002)(50986999)(86362001)(8676002)(19609705001)(55016002)(25786009)(77096006)(9686003)(6306002)(54896002)(8936002)(6506006)(9326002)(606005)(236005)(53936002)(122556002)(4326008)(81166006)(3846002)(491001)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: a1f5cba8-7568-4920-fae7-08d476b183ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006041)(93001041)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0261CCEEDF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 14:40:15.5716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUyM2K7vW7h8dsRBm0HeS2mNhxksTj25i6b A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyvkzuYS84nlBx4/Fn9gbGl2FdjJwcEgImEk1HZrJ3 MXJxCAmsZ5RY0H2CCcI5wShxdt4KMIdFoJdZonnhUajMNCaJfz/Xs0A4xxglHn9ayA4yjE3A RmLloe+MILaIQLDEik2PmUBsZgEriS/H/zKD2MJANSuW3GCGqHGUaPv5gwXC1pPYeakfbA6L gKrE1rObweK8AlESk5duYgWxGQVkJe5/v8cCMVNc4taT+UwQTwhILNlznhnCFpV4+fgfK8hx jALdjBIf5l0DKuIASihI3L8ZBRKXEOhmlph4YDoThHOMVeL5lkZGiG5fiWs/3kLZtRIPOhug NmRKnJ99HsqOlphyrIsNovkDk8TcDdugVstI9DdNgnpTSuLulU5GCFtG4sWdvawQZ+dL7Fw1 ixXiNUGJkzOfsExgVJuF5KNZSMpmISmDiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEFjOyr GEWLU4uTctONjPRSizKTi4vz8/TyUks2MQJTz8Etvw12ML587niIUYCDUYmH98He2xFCrIll xZW5hxglOJiVRHh/HgUK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUI JsvEwSnVwMgw1z4lyOWN0r7nJtbLb12bnv6g7/2VT9xiaqd7drE9MX++nrN5u41FDN+e5Y+m NCZ+XD1V38DmiO2yc6sfaMrFxNw/lPVQ+OyLu3zTJnD5b505++Tru01bqh+91uQV9uf7+PFs 3tFmlcIlby2uH2GZNWdPguEMle6L+VZX7zx2+dixuLo948x8JZbijERDLeai4kQA7Iy4ZzkD AAA= Archived-At: Subject: [tcpPrague] 3GPP RAN2 : On TCP-specific improvements in the RAN X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:40:54 -0000 --_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi This is an input to 3GPP-RAN2 that I wrote up recently, it will be discusse= d at a 3GPP-RAN2 meeting next week. The document addresses various intentions to optimize TCP performance in 3G= PP networks. L4S is here (briefly) introduced as a generic method to optimi= ze transport protocol performance regardless it is TCP, QUIC, .. pigeon dat= agrams... To put it short, there are two main recommendations in the paper 1) 3GPP should avoid the standardization of certain TCP specific optimiz= ations such as ACK thinning 2) 3GPP should consider new low latency technologies like L4S http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_97bis/Docs/R2-1702661.zip Abstract: "There is an ongoing discussion on the merits of TCP ACK thinning= in RAN with the objective to minimize the ACK traffic, and the merits with= ACK prioritization. This input paper discusses the actual need for such fu= nctionality and the applicability in perspective of future transport protoc= ol evolution and future evolution towards low latency access technology. In= short we conclude that no TCP-specific improvements are necessary." Enjoy /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

This is an input to 3GPP-RAN2 that I wrote up recently, it will be dis= cussed at a 3GPP-RAN2 meeting next week.

The document addresses various intentions to optimize TCP performance = in 3GPP networks. L4S is here (briefly) introduced as a generic method to o= ptimize transport protocol performance regardless it is TCP, QUIC, .. pigeon datagrams…

To put it short, there are two main recommendations in the paper<= /o:p>

1)    3GPP should avoid the standardization of certain TCP specific = optimizations such as ACK thinning

2)    3GPP should consider new low latency technologies like L4S

 

 

http://www.3gpp.org/ftp/tsg_= ran/WG2_RL2/TSGR2_97bis/Docs/R2-1702661.zip

 

Abstract: “There is an ongoing discussion on the merits of TCP= ACK thinning in RAN with the objective to minimize the ACK traffic, and th= e merits with ACK prioritization. This input paper discusses the actual need for such functionality and the applicability in perspectiv= e of future transport protocol evolution and future evolution towards low l= atency access technology. In short we conclude that no TCP-specific improve= ments are necessary.”

Enjoy

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake= is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_--