From nobody Mon Sep 19 02:14:00 2016 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 0C97812B058 for ; Mon, 19 Sep 2016 02:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 sfcxt0iknl0a for ; Mon, 19 Sep 2016 02:13:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2DCB312B01E for ; Mon, 19 Sep 2016 02:13:57 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-39-57dfac520770 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 03.B7.31035.25CAFD75; Mon, 19 Sep 2016 11:13:55 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 19 Sep 2016 11:13:54 +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=u9m60a+0qNeSvZZgqsIniPyYmhijVneLuXS2OKuCpaY=; b=aK+OJVKbhCHgTu9mKrl/MdXETO/pvKJQb63fydDwnfz1gUFZIhF05FUg9pDQDJLftBfRcNv8ti++gwo5r/kwEDnuL2EeqcsXWdnnZmn4NS+Dh87rf6Gt92S0rZcuw2Wl0F5FBXvidlmEEBVb61ZmLOJrI4Xm9iImSKJOcL4Px+Y= 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_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Mon, 19 Sep 2016 09:13:53 +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.0587.019; Mon, 19 Sep 2016 09:13:53 +0000 From: Ingemar Johansson S To: "'tcpprague@ietf.org'" Thread-Topic: TCP Prague progress and ideas Thread-Index: AdISViNPIZ62s6OiQfCJKrGKXkpj2Q== Date: Mon, 19 Sep 2016 09:13:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-office365-filtering-correlation-id: 04091755-9f57-4a3c-a699-08d3e06d46fb x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:9E7KMdXXAG0B1oYYeC+9oB7RbdphyGRARJA6Qa5+B/lY5eu+YlHL9Mu6Q6Ai+5DvNMBuxG1AKZEuBd/rwj77D9uuofLqWYYv9pvuMyy6EB7u0WVC7c2JA53mMpaYyyJE5UnyNB/lyBNFEDZ1700xJAI635CQUG76PN0RGG+H2VXwG8aasgcSVmvbuqNNhpJt+LJMpuVYqO5kySXtOHACYVOiGEpTagrGW6eH4D+0umI0u2NNCengfKyjMArVaBQgM6Vdo4T9aljanBpeB9CZH6+Zq7WQuxIrPcPcBH7oZJU=; 5:n9mvwuTR5BODOf6RfcFbjAHTSaYoVS3k2kXWqN7AtIg6S7rnpoc255EPcdD6vR4edWwXa9wKbMmWsNZDVWqNeuOLKUiyWutU6NxMPqzAray1BKqFTl1ymixbzUebr2ZeYIWiv9k9BzyI8FCCuxuwUA==; 24:NoJmMD7O3TZl2yUL8tSuiGJX1ePKmu/H7HViCUxotva4yjTBcNVmoSQMsEluCFnTEFZ41nPHHjTzBKKw9ll5na8vo2Z0onXQfFkr50w/EqI=; 7:aO0NmuAiVG1oyogwtSh+wca3CV5+17wbwR8NRYEULpk30Stp++FLFns/eTBCwPLhbvZjbCea+PO1wJQoVn7bix4Tqax6z7pG7K7oBJGlsyZC96SWrhYNB3rcy+2pcwUAPcrfXPnyX2g68PfhdiB3S/XVTrLBjRqu1lykH1rUjWjc789e2LIoRhKpzA1IZvXbYR5u2psFgMawNLYnIdn+/QeoGqOadhVo6kvYXcQq8XE4yNhRbSDXD1+yPGKKKn0FGgW456xIx52JEAtdWsZGHWojoSknaONibOEoxIgXRzlBykMdwhFGdtLSzOnMIIfE x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;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:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0070A8666B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(106356001)(92566002)(4001430100002)(102836003)(77096005)(97736004)(81156014)(81166006)(586003)(8676002)(19609705001)(107886002)(15975445007)(9686002)(189998001)(2900100001)(229853001)(6116002)(10400500002)(19300405004)(66066001)(9326002)(68736007)(3846002)(8936002)(790700001)(3280700002)(101416001)(54356999)(16236675004)(33656002)(19580405001)(110136003)(122556002)(11100500001)(5660300001)(7696004)(19625215002)(86362001)(105586002)(76576001)(50986999)(2906002)(3660700001)(74316002)(7846002)(87936001)(19580395003)(4326007)(7736002)(8666005)(5002640100001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3480771E801039E827A30D7C2F40DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2016 09:13:53.5076 (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: H4sIAAAAAAAAA02Sa0jTURjGOftflQYnry/qh1hZlKjdlFUSBUqD6EYfDMts6l8d6rTNLKXC C2JKluDEKUWuNK8jtFIJr0M3M0PLS2nKDBfljTJLK1FyO0Z++73P874P54HDUw4mxo1XKJME lVIeJ2Ht6eJzjSe9z9aag3cX90ukXR9LGalxsVwkzfpUzUpnbk8iaWFaB32EkU2b+xlZWdlv kWzxXR0jy2pa4WQZiw/Z00yIfUCkEKdIFlS+hy/ZxyyZ5rjElkPX9GNRacjil4vseMD7oTq/ hslF9rwDfoKgqHGeJkM3gp6le5x1oHEeBdktPzniFIjgRaeGJYMRwf3sFcYaxuIAqDIsISs7 YV9oG/9gy6KwTgQN7aO01XDE2+HryCpDlrzgT9cQRdgHMosKOSvT2BPqbz2yBYlxCJh17TYd YRdY6qkVWZnCrjBqeSAiLTCUNfdRhJ1hapLkIxwB30fyGKJvAVPlHEv4BPRWfrM1AKznYHK0 nCNGECy0dq8vKcD0eoAmfB40xtz1gwYEjf1v1w88QHNnjiZGLgvaV4M2wwELUKHPQqSyG4wP 5qyzB3wZa1l7Er9WIQFmm67mox0lGwqV/HdKbP03w8tiC01WfOB9oYYl7AWPdTMUYW/Qrhro jXop4qqRs1pQh8dH793nI6gUEWp1gtJHKSTVo7Xv1fFs2bMJDcweNSDMI8km8cRNc7ADI09W p8QbEPCUxElcVLUmiSPlKamCKiFMdSVOUBuQO09LXMX+VgtHy5OEWEFIFFT/XBFv55aGDuqr Q4U6lmKWj3cGsTOx6YGJ5vD+SPfFdoVWOVHz3PQ0bOsPnTipmZ04M+tdvzB8sTVj2tlRmRPo J7rrbkw91VdlsYx0U6GlBY4j805RO3sD/JdvVOijwj/7D10vDZzFOi2SuEy2GdM72DfcgQvh v4a3rWZePjYVIoksofMltDpGvmcXpVLL/wKuFsWWWgMAAA== Archived-At: Cc: marcelo bagnulo braun , Praveen Balasubramanian , Ingemar Johansson S , "Bob Briscoe \(ietf@bobbriscoe.net\)" , "De Schepper, Koen \(Nokia - BE\)" Subject: [tcpPrague] TCP Prague progress and ideas X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 19 Sep 2016 09:13:59 -0000 --_000_DB4PR07MB3480771E801039E827A30D7C2F40DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have started to simulate DualQ/L4S and DCTCP and try to get an understand= ing of the flaws with DCTCP. One (obvious) issue I see is that slowstart can exit too quickly. I tried w= ith a dirty hack to just ignore the 1st few ECE and that solved the issue i= n one experiment setup but more brain exercise is needed here I guess. Do you have any initial ideas and thoughts on how to improve an evolved DCT= CP --> TCP Prague. /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 The secret of getting ahead is getting started Mark Twain =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_DB4PR07MB3480771E801039E827A30D7C2F40DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I have started to simulate DualQ/L4S and DCTCP and t= ry to get an understanding of the flaws with DCTCP.

One (obvious) issue I see is that slowstart can exit= too quickly. I tried with a dirty hack to just ignore the 1st f= ew ECE and that solved the issue in one experiment setup but more brain exe= rcise is needed here I guess.

Do you have any initial ideas and thoughts on how to= improve an evolved DCTCP =E0 TCP Prague.

 

/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<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

The secret of getting ahead is getting started

           &= nbsp;       Mark Twain

=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_DB4PR07MB3480771E801039E827A30D7C2F40DB4PR07MB348eurprd_-- From nobody Tue Sep 20 08:30:26 2016 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 2CBA612B83F for ; Tue, 20 Sep 2016 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Vfxfv5Is-a for ; Tue, 20 Sep 2016 08:30:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88B312B9B6 for ; Tue, 20 Sep 2016 08:14:07 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 7F695F602D331; Tue, 20 Sep 2016 15:14:02 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8KFE4dl003351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2016 15:14:05 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u8KFE1Dm024874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Sep 2016 17:14:04 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.121]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Tue, 20 Sep 2016 17:14:02 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Ingemar Johansson S , "'tcpprague@ietf.org'" Thread-Topic: TCP Prague progress and ideas Thread-Index: AdISViNPIZ62s6OiQfCJKrGKXkpj2QANUpzw Date: Tue, 20 Sep 2016 15:14:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_BF6B00CC65FD2D45A326E74492B2C19FB774E69AFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: marcelo bagnulo braun , Praveen Balasubramanian , "Bob Briscoe \(ietf@bobbriscoe.net\)" Subject: Re: [tcpPrague] TCP Prague progress and ideas X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 20 Sep 2016 15:30:23 -0000 --_000_BF6B00CC65FD2D45A326E74492B2C19FB774E69AFR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ingemar, I think the marking pattern during slow start depends on quite some factors= . First DualQ has currently 2 modes of marking for L4S flows: - if there are L4S only flows, hitting a queue size step-on/off marker - L4S competing with Classic, where a smooth probability is applied by the = classic AQM (for example PI2). I see 2 options to continue here: a. Accepting the 2 modes network behavior, and make TCP-Prague suppor= t both b. Making the network behavior equal in both modes Some ideas in case a: - A mix of marks and non-marks identifies Classic mode, trains of = marks the L4S mode. - In Classic mode, we expect (currently) 2 marks per rtt on averag= e, we could go to a slower increase after one mark per RTT, go back to fast= er increase if we get an RTTs no mark, stop slow start when 2 or 3 marks pe= r RTT are received. - We could limit going back to faster increase only if we didn't e= xit slow start, or use the exponential increase after X non-marked RTTs all= the time? - In L4S mode, a train indicates that threshold is hit, but maybe = not the link capacity. Pacing and inspecting the timing of ACKs could help = to estimate the available capacity. Ideas on case b: - The step function could be replaced with a virtual queue and may= be doing excess marking. Excess marking will at least give a non-on/off sig= nal before the link speed is reached indicating the amount of excess traffi= c in the queue (optionally followed by a train when the real queue gets hit= as well). There are also other possibilities. - Keeping TCP-Prague RTT dependent only for the acceleration, but = RTT INdependent for the final target convergence throughput (only depend on= P measured over your RTT) could also help to find better mechanisms (as ma= rking probability is not depending on the RTTs of other flows (at least not= in the long run)). I also think that we have to define another behavior for the congestion avo= idance. We need to get fast up to speed if BW gets available, this can't be= done with linear increase (1/W increases per non marked ack). Also making = its rate RTT independent will have its impact on increase/decrease mechanis= m. This might also reduce the dependence on a good slow start estimate? Koen. From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Ingemar Jo= hansson S Sent: maandag 19 september 2016 11:14 To: 'tcpprague@ietf.org' Cc: marcelo bagnulo braun; Praveen Balasubramanian; Ingemar Johansson S; Bo= b Briscoe (ietf@bobbriscoe.net); De Schepper, Koen (Nokia - BE) Subject: [tcpPrague] TCP Prague progress and ideas Hi I have started to simulate DualQ/L4S and DCTCP and try to get an understand= ing of the flaws with DCTCP. One (obvious) issue I see is that slowstart can exit too quickly. I tried w= ith a dirty hack to just ignore the 1st few ECE and that solved the issue i= n one experiment setup but more brain exercise is needed here I guess. Do you have any initial ideas and thoughts on how to improve an evolved DCT= CP --> TCP Prague. /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 The secret of getting ahead is getting started Mark Twain =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_BF6B00CC65FD2D45A326E74492B2C19FB774E69AFR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Inge= mar,

&n= bsp;

I think= the marking pattern during slow start depends on quite some factors. First= DualQ has currently 2 modes of marking for L4S flows:

- if th= ere are L4S only flows, hitting a queue size step-on/off marker<= /span>

- L4S c= ompeting with Classic, where a smooth probability is applied by the classic= AQM (for example PI2).

&n= bsp;

I see 2= options to continue here:

= a.       Accepting the 2 modes network behavior, and make TCP-Prague support both

= b.      Making the network behavior equal in both modes

&n= bsp;

Some id= eas in case a:

= -          A mix of marks and non-marks identifies Classic mode, trains of marks the = L4S mode.

= -          In Classic mode, we expect (currently) 2 marks per rtt on average, we coul= d go to a slower increase after one mark per RTT, go back to faster increas= e if we get an RTTs no mark, stop slow start when 2 or 3 marks per RTT are received.

= -          We could limit going back to faster increase only if we didn’t exit = slow start, or use the exponential increase after X non-marked RTTs all the= time?

= -          In L4S mode, a train indicates that threshold is hit, but maybe not the li= nk capacity. Pacing and inspecting the timing of ACKs could help to estimat= e the available capacity.

&n= bsp;

Ideas o= n case b:

= -          The step function could be replaced with a virtual queue and maybe doing e= xcess marking. Excess marking will at least give a non-on/off signal before= the link speed is reached indicating the amount of excess traffic in the queue (optionally followed by a train = when the real queue gets hit as well). There are also other possibilities.<= o:p>

= -          Keeping TCP-Prague RTT dependent only for the acceleration, but RTT INdepe= ndent for the final target convergence throughput (only depend on P measure= d over your RTT) could also help to find better mechanisms (as marking probability is not depending on the RTT= s of other flows (at least not in the long run)).

&n= bsp;

I also = think that we have to define another behavior for the congestion avoidance.= We need to get fast up to speed if BW gets available, this can’t be = done with linear increase (1/W increases per non marked ack). Also making its rate RTT independent will have its impact= on increase/decrease mechanism. This might also reduce the dependence on a= good slow start estimate?

&n= bsp;

Koen.

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: maandag 19 september 2016 11:14
To: 'tcpprague@ietf.org'
Cc: marcelo bagnulo braun; Praveen Balasubramanian; Ingemar Johansso= n S; Bob Briscoe (ietf@bobbriscoe.net); De Schepper, Koen (Nokia - BE)
Subject: [tcpPrague] TCP Prague progress and ideas=

 

Hi

 

I have started to simulate Dual= Q/L4S and DCTCP and try to get an understanding of the flaws with DCTCP.

One (obvious) issue I see is th= at slowstart can exit too quickly. I tried with a dirty hack to just ignore= the 1st few ECE and that solved the issue in one experiment set= up but more brain exercise is needed here I guess.

Do you have any initial ideas a= nd thoughts on how to improve an evolved DCTCP =E0 TCP Prague.

 

/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

<= a href=3D"mailto:ingemar.s.johansson@ericsson.com">ingemar.s.joh= ansson@ericsson.com<= /span>

<= a href=3D"www.ericsson.com">www.ericsson.com

 

The secret of getting ahead is getting s= tarted

      &nbs= p;            Mark T= wain

=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_BF6B00CC65FD2D45A326E74492B2C19FB774E69AFR711WXCHMBA05z_-- From nobody Fri Sep 30 15:42:35 2016 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 2686312B004; Fri, 30 Sep 2016 15:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=xeweg/Mp; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=CNqLQ6hn 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 irESwlQBzgqk; Fri, 30 Sep 2016 15:42:32 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 2BE98128B44; Fri, 30 Sep 2016 15:42:29 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=WtL6iX933+PLAd3lrkqJtalB+mq9HQFHr6b1FH2/YLnEC8q2jNXFp8Ou yc1xllN4gSVullhYYIg9fgkSP7/pvNZ8heCpJeEfA6gWhaaUBIUt7AdQL OofjPvDmp2vaxt1O3O/7jgLmHhyg0wVN4X78OzyjmkSsxlqV01vtiBTmk w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1475275352; x=1506811352; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jAWFqj/Lwf1UWV+a2ZSE9aCDKWLqJFYdxkzylF8JLSM=; b=xeweg/MpjzAXLRCEVlofRAIF6qjdvKWs3kBlHLIagvXYWZ/eTlZ6+DlJ h6GOp3THT41Pay6TSO3CC19gRh0mvtczlAxA2vT9X5dl7egec9xKfe9zM xa1SelFNrM9OrI77xqf8KdRWYPNQv/Hb2lrdTQFIumQjRyO8QpN1VxD3t w=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2016 17:42:28 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2016 04:42:27 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8UMgQAW020766 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Sep 2016 18:42:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u8UMgQAW020766 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1475275346; bh=oDt6lAQNW8PUzuWRzUa5xten0Ro=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=CNqLQ6hnzF21U7DX5vBqMXTBU63XWPQaQKOTikx3wlvSt0ZpunVRG6oCQozhSi1SN dDmVB/htHNGovw/LV6oLcAeT/4yQxADUbDLEzfE4X4IOmeYBbxz1PgPUQBtBuWidap EiTNEdsCLp7a6w0Yb8GU192DSmst4u9RPciQqLvw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u8UMgQAW020766 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 30 Sep 2016 18:42:08 -0400 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8UMgA3o000334 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 30 Sep 2016 18:42:11 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0266.001; Fri, 30 Sep 2016 18:42:10 -0400 To: "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSG2lu78AbxlWIl0mB4/rUtZANMqCSn4Dg Date: Fri, 30 Sep 2016 22:42:09 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> In-Reply-To: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 30 Sep 2016 22:42:34 -0000 This is the process-oriented draft on ECN experimentation that I promised a= t the TSVWG meeting in Berlin. Comments are welcome, but please keep the process focu= s in mind - the intent is to leave documentation of the actual ECN changes and rational= e to the referenced drafts that document the ECN experiments. Thanks, --David -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, September 30, 2016 6:24 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Explicit Congestion Notification (ECN) Experiment= ation Author : David Black Filename : draft-black-tsvwg-ecn-experimentation-00.txt Pages : 10 Date : 2016-09-30 Abstract: Multiple protocol experiments have been proposed that involve changes to Explicit Congestion Notification (ECN) as specified in RFC 3168. This memo summarizes the proposed areas of experimentation to provide an overview to the Internet community and updates RFC 3168, a Proposed Standard RFC, to allow the experiments to proceed without requiring a standards process exception for each Experimental RFC to update RFC 3168. This memo also makes related updates to the ECN specification for RTP in RFC 6679 for the same reason. Each experiment is still required to be documented in an Experimental RFC. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-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