From nobody Wed Aug 3 02:57:22 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 5027312D0F5; Wed, 3 Aug 2016 02:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 F1tNE7bABlWl; Wed, 3 Aug 2016 02:57:15 -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 0988E12D0DD; Wed, 3 Aug 2016 02:57:14 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DB2858303D26F; Wed, 3 Aug 2016 09:57:10 +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 u739vDAk013665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2016 09:57:13 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 u739vAMF012602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Aug 2016 11:57:12 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.89]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 3 Aug 2016 11:56:53 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Dave Taht , "aqm@ietf.org" , "tcpprague@ietf.org" , bloat Thread-Topic: [aqm] what is the correct linux tc u32 match to ignore ecn but preserve tos? Thread-Index: AQHR6PVIooXbg2d9UUSb998dmwbSQKA3AyfQ Date: Wed, 3 Aug 2016 09:56:53 +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.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpPrague] [aqm] what is the correct linux tc u32 match to ignore ecn but preserve tos? 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: Wed, 03 Aug 2016 09:57:17 -0000 U2VlIGlubGluZToNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcW0g W21haWx0bzphcW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgVGFodA0KPiBT ZW50OiBkb25kZXJkYWcgMjgganVsaSAyMDE2IDE5OjI3DQo+IFRvOiBhcW1AaWV0Zi5vcmc7IHRj cHByYWd1ZUBpZXRmLm9yZzsgYmxvYXQNCj4gU3ViamVjdDogW2FxbV0gd2hhdCBpcyB0aGUgY29y cmVjdCBsaW51eCB0YyB1MzIgbWF0Y2ggdG8gaWdub3JlIGVjbiBidXQNCj4gcHJlc2VydmUgdG9z Pw0KPiANCj4gSSBjYW4ndCBldmVyIGdldCBteSBlbmRpYW5lc3Mgc3RyYWlnaHQsIGFuZCBJIGZp Z3VyZSB0aGF0IHNvbWVvbmUgaGVyZQ0KPiBtaWdodCAianVzdCBrbm93Ig0KPiANCj4gRG8gSSB1 c2UgbWF0Y2ggdTggMHhmYyBvciAweGNmPw0KPiANCj4gdGMgZmlsdGVyIGFkZCBkZXYgJERFViBw YXJlbnQgMTowIHByb3RvY29sIGlwIHByaW8gMTAgdTMyIFwNCj4gICAgICAgbWF0Y2ggaXAgdG9z IDB4MTAgMHhmZiAgZmxvd2lkIDE6MTANCj4gDQo+IChhbSB0cnlpbmcgdG8gcmV2aXNlIHRoaXMg ZnJvbSBpbiBmcm9udCBvZiBhIG1hYzoNCj4gaHR0cHM6Ly93d3cuYnVmZmVyYmxvYXQubmV0L3By b2plY3RzL2Nlcm93cnQvd2lraS9Xb25kZXJzaGFwZXJfTXVzdF9EaWUvDQo+ICkNCj4gDQo+IEJv bnVzIHBvaW50cyBpZiB5b3UgY2FuIGNvbWUgdXAgd2l0aCB0aGUgcmlnaHQgdGMgZmlsdGVyIGxp bmUgZm9yIGlwdjYuDQo+IA0KPiBXaGF0IEkgd291bGQgcHJvYmFibHkgZG8gaXMgaGF2ZSBhIGZp bHRlciBjaGFpbiB0byB0aGVuIGNsYXNzaWZ5IHRoZQ0KPiB0aGluZyBmdXJ0aGVyIGZvciBMNHMs IGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgaG93IG9yIHdoZXJlIEknZCBkaXJlY3QNCj4gQ0UgbWFy a2luZ3MgY29ycmVjdGx5LiAoPykNCj4gDQo+IEhvdyBkb2VzIGl0IGhhcHBlbiBpbiB0aGUgcGky IGNvZGU/IGlzIHRoYXQgb24gZ2l0aHViIHNvbWV3aGVyZT8NCg0KUGkyIGNvZGUgaXMgaW4gaHR0 cHM6Ly9naXRodWIuY29tL29sZ2Fiby9kdWFscGkyDQoNCldlIGRvbid0IHVzZSB0YyBmaWx0ZXJz IHRvIGNsYXNzaWZ5LCB0aGUgY2xhc3NpZmljYXRpb24gYW5kIGR1YWxxIGlzIHBhcnQgb2YgdGhl IGFxbS4gRnJvbSBhIHRjIHBvaW50IG9mIHZpZXcsIGl0IGlzIGEgc2luZ2xlIHFkaXNjLg0KDQpU aGUgTDRTIGNsYXNzaWZpZXIgaXMgb25seSBvbmUgYml0OiB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQg b25lIGluIHRoZSBlY24gKGFuZCBhbHNvIHRvcykgZmllbGQuIFRoaXMgd2F5IGJvdGggZWN0KDEp IGFuZCBjZSBhcmUgdHJlYXRlZCBhcyBMNFMuIERlZmF1bHQgdGhlIGN1cnJlbnQgcGkyIHdpbGwg Y2xhc3NpZnkgYWxzbyBlY3QoMCksIHRvIHdvcmsgd2l0aCBEQ1RDUC4gWW91IGNhbiB1c2UgdGhl IG9wdGlvbiAiZWN0MV9zY2FsIiB0byB0cmVhdCBvbmx5IGVjdDEgYXMgYSBzY2FsYWJsZSBDQyAo c28gdG8gc3VwcG9ydCBjbGFzc2ljIGVjbikuIEFsc28gcGVyIGRlZmF1bHQgbm8gRHVhbFEgaXMg ZW5hYmxlZC4gRm9yIERDVENQIHdpdGggRHVhbFEsIHNwZWNpZnkgdGhlICJkdWFscSIgb3B0aW9u LCB3aGljaCBwdXRzIGFsc28gZWN0KDApIGluIHRoZSBMNFMgcXVldWUuIFRoZSBvcHRpb24gZHVh bHFfZWN0MSBwdXRzIG9ubHkgZWN0KDEpIGFuZCBjZSBpbiB0aGUgTDRTIHF1ZXVlIGFuZCBlY3Qo MCkgaW4gdGhlIGNsYXNzaWMgcXVldWUuDQoNCktvZW4uDQoNCj4gDQo+IC0tDQo+IERhdmUgVMOk aHQNCj4gTGV0J3MgZ28gbWFrZSBob21lIHJvdXRlcnMgYW5kIHdpZmkgZmFzdGVyISBXaXRoIGJl dHRlciBzb2Z0d2FyZSENCj4gaHR0cDovL2Jsb2cuY2Vyb3dydC5vcmfjr53jr58NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFxbSBtYWls aW5nIGxpc3QNCj4gYXFtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXFtDQo= From nobody Mon Aug 8 04:40:58 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 369CF12B05F; Mon, 8 Aug 2016 04:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, 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 7p-yFj2S8SvR; Mon, 8 Aug 2016 04:40:49 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A152112D0DD; Mon, 8 Aug 2016 04:40:48 -0700 (PDT) Received: from EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Aug 2016 12:40:44 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 12:40:46 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 12:40:45 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Mon, 8 Aug 2016 12:40:45 +0100 From: To: , Thread-Topic: draft minutes for the L4S BoF Thread-Index: AdHxaZPbt6fbmttkTOK3j/4dW6cAWw== Date: Mon, 8 Aug 2016 11:40:44 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: multipart/alternative; boundary="_000_a1a361009951426e803daf3e5bcf37eerew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Cc: lars@netapp.com Subject: [tcpPrague] draft minutes for the L4S BoF 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, 08 Aug 2016 11:40:53 -0000 --_000_a1a361009951426e803daf3e5bcf37eerew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the draft minutes for the L4S BoF. Many thanks for Steve Blake for= the excellent notes. Please send any corrections /improvements. Thanks -- BOF: Low Latency Low Loss Scalable throughout (L4S) Draft Agenda for Berlin TUESDAY, July 19, 2016 1400-1600 Afternoon Session I Potsdam I Chairs: Lars Eggert, Philip Eardley =3D=3D Draft agenda =3D=3Ds 1. Introduction - Chairs Tim Chown: is there a mailing list? Yes: tcpprague@ietf.org 2. The problem and very high-level solution - Bob Briscoe - Yuchung (Google): do you need to track the per-flow state? - Bob: no, just ECN bit - Yuchung: Does the AQM for classic traffic turn the elephant into a rabbi= t? - Linda Dunbar (Huawei): How do you prevent the problem of queueing in a co= re router? Do you need this there? - Bob: Usually you don't get queueing in a core router. You don't want drop= or delay in the core. - Bob: Once you deal with your primary bottleneck, in the longer term you c= ould put a queue like this in, but queuing tends to get pushed to the edge. 3. Demo: L4S in action - Koen De Schepper - Jana Iyengar: explain the second graph - Koen: One cluster of delay is retransmit timeout of 200ms - Dave Taht (bufferbloat.net): what was the baseline RTT? - Koen: 7 msec - Dave Taht: do you have data with larger (> 100msec) RTTs? - Koen Yes 4. L4S Applicability to Mobile, without flow inspection - Kevin Smith - no questions/comments 5. L4S in a 4G/5G context - Ingemar Johansson - no questions/comments 6. DCTCP evolution - Praveen Balasubramanian - no questions/comments 7. Discussion about the technology - Yuchung: Curvy Red on classic traffic doesn't solve the whole problem, st= ill need DCTCP - Bob: DCTCP gives lower latency. Want to enable new applications to motiv= ate deployment - Yuchung: can't you tune your AQM - Bob: if you tune too hard, lose throughput - Magnus Westerlund: interactions with video interface (e.g., frame interva= ls) - Koen: concern about rapid changing throughput. We can guarantee low late= ncy, but throughput might change rapidly. Application must adapt. - Magnus: how well does the congestion signal interact, different from what= a TCP connection would see. - Koen: allows bursts (unlike FQ). - Dave Taht: work is an outgrowth of the AQM working group. What AQM has s= pecified is vastly superior to what has been deployed today. Would find yo= ur presentation more convincing if you compared it to FQ-Codel. - Koen: could show you. - Dave Taht: FQ-Codel show near-zero latency for many forms of traffic. - Mat Ford: How does the end system know that it is on a network with Dual-= Q coupled AQM? - Praveen: end host doesn't know - Bob: DCTCP just reverts to TCP Reno upon loss. With classic ECN end syst= em would see delay before ECN signal and could guess that class ECN would b= e in use. - Yuchung : should we change routers before we update hosts? - Koen: in parallel, gradually. DCTCP exists today. You can make a TCP th= at works in both. - Yuchung: Does this exist in the drafts? - Bob: need fallback if classic ECN is in use instead of L4S ECN - Pat Thaler (Broadcom): cover datacentre as well as carrier? - Bob: yes. original reason I started doing this was that there were too ma= ny datacentres to deploy DCTCP (in BT). Bottleneck is likely to be on the = ToR switch; solution for multi-tenant DCs. - Pat Thaler: some apps care about low lost /latency; others don't. - David Black: Where are the incentives to keep the other senders out of th= e low latency queue? - Bob: you've misunderstood: all large flows can also be in the L4S queue .= .. - David Black: Assumes only DCTCP is supposed to use ECT(1), what is the in= centive for not using this codepoint by other applications that are not DCT= CP? - Koen: same as today, you could always just ignore ECN signal. Can employ= other techniques such as rate limiting to stop cheating. - Lars: can someone misbehaving destroy the queue for everyone? - Praveen: will react badly to loss. - David Black: some degree of trust that ECT1 will be set appropriately. - Bob: This needs to be mentioned in the security considerations section of= draft. - Jana: It's not just a security consideration - it does not need to be an = attacker, just a mistaken use. - Koen: This is the same situation as with current network with classic ECN= . Eventually you just start dropping packets, as you do in any other AQM. - Jana: The AQM WG may be about to close, what do you think your recommenda= tion will be to address this? - Lars: Hold this question until the end of the session. - Roland Bless : AQM can achieve low delay if you have more than a few flow= s. Otherwise, you need to change TCP. - Koen: tcpprague has to decide how to be scalable, future safe. Updates ma= y require changes to the queues in routers. - Roland Bless : It's not so easy to update the network routers after a cha= nge. - Christian Huitema: There is a lot of discussion about the relation of ECN= feedback with two queues vs. multi-queue (e.g., FQ-Codel). With flow isol= ation, each flow can have its own feedback. If you look at what you are do= ing, you are specifying a new network feedback mechanism (please warn me ve= ry quickly if the queueing is going up). I have reservations about embeddi= ng the square root coupling into the mechanism; TCP is not square root. It= 's a hack. - Koen: with slow start, short flows don't get any feedback. With short RT= T you can respond quickly. Not so much with longer RTT flows. There are ot= her mechanisms for short flows. - CH: very small fraction of flows are long flows. - Koen: video quality performance depends on throughput and low latency. V= R video needs lower latency/higher throughput. - CH: be careful about hacks - Bob: I agree it is worrying to put a formula into the architecture. Havi= ng a shallow threshold on L4S side allows you to test the capacity more qui= ckly to get your short flows going faster. - Colin Perkins: good story for not marking a class TCP traffic with ECT(1)= . Not sure about RTP conferencing application; incentives might not apply = in that case. - Bob: I want those flows in the L4S queue. - Colin: If I build a non-adaptive video app I may just ignore all the CE-m= arks, that's an important case to consider for other apps. - Bob: Koen has done experiments. If this thing moves to loss, will self-c= ontrol itself. Problem is the same as what we have now. - Koen: If someone sends non-CC traffic above bottleneck share, same proble= m happens. - Colin: The disadvantage is that you push the TCP flows away quickly. - Koen: today as well. Don't necessarily have a bigger effect because the = queues are smaller. - Yuchung: What about delay-based CC? - Koen: There is some discussion ongoing. Hard for delay based CC to coexi= st with loss based CC (fairness). - Yuchung: ? - Koen: fairness, I don't know - Bob: I want operators to change things to the right way quickly. - Yuchung: So, you think ECN is a more straightforward approach? - Bob: if delay is a problem, using delay measurements to control the syste= m won't help. - Koen: A combination of loss and delay can help (improve ECN feedback). - Lars: don't want to go into loss vs. delay debate. - Jana: The model here is a separation of queues in bottleneck routers; one= low latency, one marking ECN bits. Sender response to that also needs to = be considered - - you could look at doing something different in TCP-Prague= . - (no answer) - Phil: question about FQ-Codel comparison; see Koen at the end. 8. Work required by the IETF - Marcelo Bagnulo 9. Discussion of the work required by IETF - Colin Perkins: think you are missing some significant components. Only m= entioned TCP and IP. What about non-TCP transports - Marcelo: some mention of others. Think we should initially focus on TCP - Colin: existing RFCs of non-TCP transports using ECN. You are violating = MUSTs - Marcelo: and they also violate TCP MUSTs. Just updating RFC 3168 (?) is = enough - Colin: if you are updating the response at the IP level; you need to upda= te all of the other RFCs. - Bob: we have just written text that does what you suggest we do. - Colin: list missing things like circuit breakers in AVT. - Bob: updating existing RFCs. New work can adapt. - Lars: you are changing things underneath then. - Mirja: ongoing work we are doing anyway - Gorry: not just RFCs, they are deployed. Other areas of the IETF that wi= ll be impacted. - Bob: I checked ECN over RTP over UDP. Nobody using ECT(1). - Colin: this affects existing work. Not listed. Needs to be added. - Tim Shepard: because you are changing things underneath them, they need t= o change. But if they are using ECT0 they don't need to change. - Lars: - Tim: what changes for ECT(0)? - Colin: discuss based on this that says nothing about ECT(1). Impacting o= ther drafts even if they don't use ECT1. - Lars: proponents need to check other work that is standardized and ongoin= g to see what will be affected. - Mirja: Some changes to ECN are changes that are independent of L4S. Thes= e need to be changed anyway. - Christian H: want to change to have high-volume feedback from the network= . Need to do the checks of other work. - Colin: impacts more WGs than tsvwg. - Lars: already a problem that the tsvwg folks need to take into account. - David Black: author of RFC 3168 and tsvwg chair - agree with Colin. Expe= rimentation is called for. RFC3168 prohibits experimentation? Draft to ch= ange ECN response is being split into two drafts. What do we need to do to= enable experimentation. If we open this up, we are tinkering with things = that could break the Internet. What are the appropriate controls to allow = us to experiment responsibly. - Magnus W: feels that the assumption that everyone is using ECT(0) today i= s wrong. Some folks may be using ECT(1) today. APIs allow applications to= set ECT will allow more applications to use ECT(1). - Koen: Apps can detect ECN-CE response behaviour that has delay and adapt. - Magnus W: If you have an API to set the ECN bits for UDP, then you may im= mediately expect to see more use of this codepoint... 10. Polls - Chairs - Lars: do people believe that they understand the proposal being brought f= orward? * rough consensus for understanding - Lars: do you believe this is something the IETF should take on * strong consensus for yes - Lars: show hands if you want to help with the work * approximately 20 hands up. Send an email to tcpprague@ietf.org if you ar= e willing to help. State if you are willing to review documents. - Jana: question about who is willing to deploy. - Lars: please show your hand if you build equipment or run networks * 15-20 hands - Mirja : do people believe that the IETF is able to do this work? - Lars: if you believe, please hum * strong consensus yes - Jana: different pieces: dual-Q, response - Jana: does tcpprague belong in iccrg? - Mirja: the only thing that really needs standardization is the marking to= discriminate DCTCP vs. classic - Phil: Koen will show demo now. --_000_a1a361009951426e803daf3e5bcf37eerew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Her= e are the draft minutes for the L4S BoF. Many thanks for Steve Blake for th= e excellent notes.

Ple= ase send any corrections /improvements.

Tha= nks

 

--<= o:p>

 

BOF= : Low Latency Low Loss Scalable throughout (L4S) Draft Agenda for Berlin

TUE= SDAY, July 19, 2016

140= 0-1600  Afternoon Session I Potsdam I

Cha= irs: Lars Eggert, Philip Eardley

 

=3D= =3D Draft agenda =3D=3Ds

1. = Introduction - Chairs

 

Tim= Chown: is there a mailing list?

Yes= : tcpprague@ietf.org

 

2. = The problem and very high-level solution - Bob Briscoe

 

- Y= uchung (Google): do you need to track the per-flow state?=

- B= ob: no, just ECN bit

- Y= uchung:  Does the AQM for classic traffic turn the elephant into a rab= bit?

- L= inda Dunbar (Huawei): How do you prevent the problem of queueing in a core = router? Do you need this there?

- B= ob: Usually you don't get queueing in a core router. You don't want drop or= delay in the core.

- B= ob: Once you deal with your primary bottleneck, in the longer term you coul= d put a queue like this in, but queuing tends to get pushed to the edge.

 

 

3. = Demo: L4S in action - Koen De Schepper

 

- J= ana Iyengar: explain the second graph

- K= oen:  One cluster of delay is retransmit timeout of 200ms

- D= ave Taht (bufferbloat.net): what was the baseline RTT?

- K= oen: 7 msec

- D= ave Taht: do you have data with larger (> 100msec) RTTs?

- K= oen Yes

 

 

4. = L4S Applicability to Mobile, without flow inspection - Kevin Smith

 

- n= o questions/comments

 

5. = L4S in a 4G/5G context - Ingemar Johansson

 

- n= o questions/comments

 

6. = DCTCP evolution - Praveen Balasubramanian

 

- n= o questions/comments

 

7. = Discussion about the technology

 

- Y= uchung: Curvy Red on classic traffic doesn't solve the whole problem, still= need DCTCP

- B= ob: DCTCP gives lower latency.  Want to enable new applications to mot= ivate deployment

- Y= uchung: can't you tune your AQM

- B= ob: if you tune too hard, lose throughput

- M= agnus Westerlund: interactions with video interface (e.g., frame intervals)=

- K= oen: concern about rapid changing throughput.  We can guarantee low la= tency, but throughput might change rapidly.  Application must adapt.

- M= agnus: how well does the congestion signal interact, different from what a = TCP connection would see.

- K= oen: allows bursts (unlike FQ).  

- D= ave Taht: work is an outgrowth of the AQM working group.  What AQM has= specified is vastly superior to what has been deployed today.  Would find your presentation more convincing if you compared = it to FQ-Codel.

- K= oen: could show you.

- D= ave Taht: FQ-Codel show near-zero latency for many forms of traffic.

- M= at Ford: How does the end system know that it is on a network with Dual-Q c= oupled AQM?

- P= raveen: end host doesn’t know

- B= ob: DCTCP just reverts to TCP Reno upon loss.  With classic ECN end sy= stem would see delay before ECN signal and could guess that class ECN would be in use.

- Y= uchung : should we change routers before we update hosts?=

- K= oen: in parallel, gradually.  DCTCP exists today.  You can make a= TCP that works in both.

- Y= uchung: Does this exist in the drafts?

- B= ob: need fallback if classic ECN is in use instead of L4S ECN

- P= at Thaler (Broadcom): cover datacentre as well as carrier?

- B= ob: yes. original reason I started doing this was that there were too many = datacentres to deploy DCTCP (in BT).  Bottleneck is likely to be on the ToR switch; solution for multi-tenant DCs.

- P= at Thaler: some apps care about low lost /latency; others don't.=

- D= avid Black: Where are the incentives to keep the other senders out of the l= ow latency queue?

- B= ob: you've misunderstood: all large flows can also be in the L4S queue ...<= o:p>

- D= avid Black: Assumes only DCTCP is supposed to use ECT(1), what is the incen= tive for not using this codepoint by other applications that are not DCTCP?

- K= oen: same as today, you could always just ignore ECN signal.  Can empl= oy other techniques such as rate limiting to stop cheating.

- L= ars: can someone misbehaving destroy the queue for everyone?

- P= raveen: will react badly to loss.

- D= avid Black: some degree of trust that ECT1 will be set appropriately.<= /o:p>

- B= ob: This needs to be mentioned in the security considerations section of dr= aft.

- J= ana: It's not just a security consideration - it does not need to be an att= acker, just a mistaken use.

- K= oen: This is the same situation as with current network with classic ECN.&n= bsp; Eventually you just start dropping packets, as you do in any other AQM.

- J= ana: The AQM WG may be about to close, what do you think your recommendatio= n will be to address this?

- L= ars: Hold this question until the end of the session.

- R= oland Bless : AQM can achieve low delay if you have more than a few flows.&= nbsp; Otherwise, you need to change TCP.

- K= oen: tcpprague has to decide how to be scalable, future safe. Updates may r= equire changes to the queues in routers.

- R= oland Bless : It's not so easy to update the network routers after a change= .

- C= hristian Huitema: There is a lot of discussion about the relation of ECN fe= edback with two queues vs. multi-queue (e.g., FQ-Codel).  With flow isolation, each flow can have its own feedback.  If you loo= k at what you are doing, you are specifying a new network feedback mechanis= m (please warn me very quickly if the queueing is going up).  I have r= eservations about embedding the square root coupling into the mechanism; TCP is not square root.  It's a hack.

- K= oen: with slow start, short flows don't get any feedback.  With short = RTT you can respond quickly.  Not so much with longer RTT flows. There are other mechanisms for short flows.

- C= H: very small fraction of flows are long flows.

- K= oen: video quality performance depends on throughput and low latency. = VR video needs lower latency/higher throughput.

- C= H: be careful about hacks

- B= ob: I agree it is worrying to put a formula into the architecture.  Ha= ving a shallow threshold on L4S side allows you to test the capacity more quickly to get your short flows going faster.=

- C= olin Perkins: good story for not marking a class TCP traffic with ECT(1).&n= bsp; Not sure about RTP conferencing application; incentives might not apply in that case.

- B= ob: I want those flows in the L4S queue.

- C= olin: If I build a non-adaptive video app I may just ignore all the CE-mark= s, that's an important case to consider for other apps.

- B= ob: Koen has done experiments.  If this thing moves to loss, will self= -control itself.  Problem is the same as what we have now.

- K= oen: If someone sends non-CC traffic above bottleneck share, same problem h= appens.

- C= olin: The disadvantage is that you push the TCP flows away quickly.

- K= oen: today as well.  Don't necessarily have a bigger effect because th= e queues are smaller.

- Y= uchung: What about delay-based CC?

- K= oen: There is some discussion ongoing.  Hard for delay based CC to coe= xist with loss based CC (fairness).

- Y= uchung: ?

- K= oen: fairness, I don't know

- B= ob: I want operators to change things to the right way quickly.<= /span>

- Y= uchung: So, you think ECN is a more straightforward approach?

- B= ob: if delay is a problem, using delay measurements to control the system w= on't help.

- K= oen: A combination of loss and delay can help (improve ECN feedback).<= /o:p>

- L= ars: don't want to go into loss vs. delay debate.

- J= ana: The model here is a separation of queues in bottleneck routers; one lo= w latency, one marking ECN bits.  Sender response to that also needs to be considered - - you could look at doing something = different in TCP-Prague.

- (= no answer)

- P= hil: question about FQ-Codel comparison; see Koen at the end.

 

 

8. = Work required by the IETF - Marcelo Bagnulo

 

9. = Discussion of the work required by IETF

 

- C= olin Perkins: think you are missing some significant components.  Only= mentioned TCP and IP.  What about non-TCP transports

- M= arcelo: some mention of others.  Think we should initially focus on TC= P

- C= olin: existing RFCs of non-TCP transports using ECN.  You are violatin= g MUSTs

- M= arcelo: and they also violate TCP MUSTs.  Just updating RFC 3168 (?) i= s enough

- C= olin: if you are updating the response at the IP level; you need to update = all of the other RFCs.

- B= ob: we have just written text that does what you suggest we do.<= /span>

- C= olin: list missing things like circuit breakers in AVT.

- B= ob: updating existing RFCs.  New work can adapt.

- L= ars: you are changing things underneath then.

- M= irja: ongoing work we are doing anyway

- G= orry: not just RFCs, they are deployed.  Other areas of the IETF that = will be impacted.

- B= ob: I checked ECN over RTP over UDP.  Nobody using ECT(1).<= /span>

- C= olin: this affects existing work.  Not listed.  Needs to be added= .

- T= im Shepard: because you are changing things underneath them, they need to c= hange.  But if they are using ECT0 they don't need to change.

- L= ars:

- T= im: what changes for ECT(0)?

- C= olin: discuss based on this that says nothing about ECT(1).  Impacting= other drafts even if they don't use ECT1.

- L= ars: proponents need to check other work that is standardized and ongoing t= o see what will be affected.

- M= irja: Some changes to ECN are changes that are independent of L4S.  Th= ese need to be changed anyway.

- C= hristian H: want to change to have high-volume feedback from the network.&n= bsp; Need to do the checks of other work.

- C= olin: impacts more WGs than tsvwg.

- L= ars: already a problem that the tsvwg folks need to take into account.=

- D= avid Black: author of RFC 3168 and tsvwg chair - agree with Colin.  Ex= perimentation is called for.  RFC3168 prohibits experimentation?  Draft to change ECN response is being split into two drafts.  What do= we need to do to enable experimentation.  If we open this up, we are = tinkering with things that could break the Internet.  What are the app= ropriate controls to allow us to experiment responsibly.<= /p>

- M= agnus W: feels that the assumption that everyone is using ECT(0) today is w= rong.  Some folks may be using ECT(1) today.  APIs allow applications to set ECT will allow more applications to use ECT(1).<= o:p>

- K= oen: Apps can detect ECN-CE response behaviour that has delay and adapt.

- M= agnus W: If you have an API to set the ECN bits for UDP, then you may immed= iately expect to see more use of this codepoint...

 

 

10.= Polls - Chairs

 

- L= ars: do people believe that they understand the proposal being brought forw= ard?

* r= ough consensus for understanding

 

- L= ars: do you believe this is something the IETF should take on

* s= trong consensus for yes

- L= ars: show hands if you want to help with the work

* a= pproximately 20 hands up.  Send an email to tcpprague@ietf.org if you = are willing to help.  State if you are willing to review documents.

- J= ana: question about who is willing to deploy.

- L= ars: please show your hand if you build equipment or run networks

* 1= 5-20 hands

 

- M= irja : do people believe that the IETF is able to do this work?<= /span>

- L= ars: if you believe, please hum

* s= trong consensus yes

- J= ana: different pieces: dual-Q, response

- J= ana: does tcpprague belong in iccrg?

- M= irja: the only thing that really needs standardization is the marking to di= scriminate DCTCP vs. classic

- P= hil: Koen will show demo now.

 

 

 

--_000_a1a361009951426e803daf3e5bcf37eerew09926dag03bdomain1sy_-- From nobody Mon Aug 8 07:52:20 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 826BB12D61C for ; Mon, 8 Aug 2016 07:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 DiEFnIcmC02t for ; Mon, 8 Aug 2016 07:52:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7412D614 for ; Mon, 8 Aug 2016 07:52:14 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C7AE790910F; Mon, 8 Aug 2016 10:52:13 -0400 (EDT) Date: Mon, 8 Aug 2016 10:52:13 -0400 From: John Leslie To: tcpPrague@ietf.org Message-ID: <20160808145213.GE4396@verdi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: [tcpPrague] "Warn me if queue is growing" 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, 08 Aug 2016 14:52:19 -0000 philip.eardley@bt.com wrote: > > Here are the draft minutes for the L4S BoF. Many thanks for Steve Blake > for the excellent notes. > > BOF: Low Latency Low Loss Scalable throughout (L4S) Draft Agenda for Berlin > ... > 7. Discussion about the technology > ... > - Christian Huitema: There is a lot of discussion about the relation of > ECN feedback with two queues vs. multi-queue (e.g., FQ-Codel). With > flow isolation, each flow can have its own feedback. If you look at > what you are doing, you are specifying a new network feedback mechanism > (please warn me very quickly if the queueing is going up). Such a signal makes a lot of sense! > I have reservations about embedding the square root coupling into the > mechanism; TCP is not square root. It's a hack. Indeed, it is a hack. Offhand, it looks like a promising hack... > - Koen: with slow start, short flows don't get any feedback. With > short RTT you can respond quickly... > - CH: very small fraction of flows are long flows. Indeed, a lot of the problem comes from short flows which never learn the queue is growing (unless the RTT growth is obvious enough not to be drowned out by noise). > - Koen: video quality performance depends on throughput and low latency. > VR video needs lower latency/higher throughput. > - CH: be careful about hacks Always valid advice; but I fear Christian may be missing the point. :^( (He's hardly alone!) I don't see the question of the difference between the two "marking" algorithms as central to this; so I'm not worried about the particular relation between them at the start of our experiment. Instead, I worry how to match the benefit of faster response (as distinct from faster delivery) to use of the short queue, and the benefit of queueing to une of the longer queue. I suggest considering whether queueing should ever be a significant delay unless queueing is specifically requested... > - Bob: I agree it is worrying to put a formula into the architecture. > Having a shallow threshold on L4S side allows you to test the capacity > more quickly to get your short flows going faster. (Bob and I agree! Surprise!) (Is there hope of getting Bob and Christian to agree?) I think it would help to separate the ideas of quick delivery and quick response... I'm not particular how we do it: I wouldn't mind if we invented a "response" which didn't deliver the whole packet... IMHO, we _can't_ promise quick delivery when congestion is present. The best we can do is promise not to delay the response. In an ideal world, we'd have a way to respond (to the sender) without needing to deliver the packet. Alas, I see no solution while source addresses are so easily forged. But we can, at least, be clear whether we're promising quicker delivery or quicker response. -- John Leslie From nobody Fri Aug 12 04:30:46 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 596C312D9FE for ; Fri, 12 Aug 2016 04:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 hHbSLKpPKZb0 for ; Fri, 12 Aug 2016 04:30:41 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9455512D9F9 for ; Fri, 12 Aug 2016 04:30:39 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id q83so21907421iod.1 for ; Fri, 12 Aug 2016 04:30:39 -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; bh=RsGwwstmgyf79WF7Ns8R2aPaWCg0r9YR+T9wCuyy1GU=; b=TGRuFyh0CrGpcSfIZXp1stAlbUQp1jQ3DtTBw7szcl0RrhTxS1vwcgkdkHWwox7Lle RIqMiC+1/zsAwdVggtYmv0gAV6bljYjCiS1OChka2+5wh173WsY4S14ZplsB3LvL8btQ C17lgTVeNw1GLDMdD3mmV+5cSIbJKs+oJ2gbM= 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; bh=RsGwwstmgyf79WF7Ns8R2aPaWCg0r9YR+T9wCuyy1GU=; b=JClPWwUnfqr3j90oo/3yyQcDrwiUL0UwpiMId4KW8rulygnI2yOvS+FTXwHdA5Ktm1 yaE94khdFeqdifkomfWE8fs1sKRXpYgVpAgXS9MosvarqlIY25UeFjLYBPhgStbk/GMs 6HCzgROf1YBKW47N9DoP0vc44mMnppsT540SecwrF0wtORCHkSeR5g7fj519COeKpk++ jXztXZkYCSd/TdlCosSoyVq89Xj2BdQBoLP1orOqEpomNXnelNtEtkv4lx9jdkbFInRn 7i2tQC9FhEfuNpcokxgZTYwt4TXz3/kLk1sN0qlDRjVw97+zThomXpk/cGR5tycp1eGy T8ng== X-Gm-Message-State: AEkoouu1C5Ie6XQALfB7vn0lWqJKqVJvjRuRTqd8F6vQKg34Uum+lx5vw5Ctp/v7siDEe7kCBu5wervBkNJMoh89JdTEL3xaz0qOy9DgdhHMOn+IB98JDCSsM+cxSWuwCsJpMU4UT+2xqQ== X-Received: by 10.107.37.198 with SMTP id l189mr16958232iol.117.1471001439087; Fri, 12 Aug 2016 04:30:39 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> In-Reply-To: <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGd4OoGFyImcsqDlVk0oY8T3VfV3QH845XxoJ1vbUA= Date: Fri, 12 Aug 2016 13:30:38 +0200 Message-ID: To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm IETF list , TCP Prague List , Yuchung Cheng Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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, 12 Aug 2016 11:30:45 -0000 Hi Marcello, I very much appreciate your draft. Even more so as it addresses one of the things I find to be a bit "disturbing" in the l4s drafts - Namely the claim that the finer saw tooth functionality of l4s/DCTCP alone solves the latency problems (while DCTCP indeed also is tuning the RTO timeout aggressively). E.g., the formulation in section 1.1 of https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/?include_t ext=1 It turns out that a TCP algorithm like DCTCP that solves TCP's scalability problem also solves the latency problem, because the finer sawteeth cause very little queuing delay. A supporting paper [DCttH15] gives the full explanation of why the design solves both the latency and the scaling problems, both in plain English and in more precise mathematical form. The explanation is summarised without the maths in [I-D.briscoe-aqm-dualq-coupled]. could benefit from a reference to your draft or the issue that you addresses here (at least for comprehensiveness). An additional comment is that new approaches to retransmissions - like TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at the moment) might fundamentally alter the picture. I.e., if retransmissions are sent pro-actively in tail loss situations then more conservative RTOs may be kept for situations where it is prudent to wait longer. Don't know if TCP TLP is so widely deployed that it is something that you should relate to even if it may be superseded by RACK. Just a thought. BR, Karen > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo > braun > Sent: 8. juli 2016 23:19 > To: tcpm IETF list > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > Hi, > > We just submitted this draft for consideration of the WG. Comments are > appreciated. > > Regards, marcelo > > > > > -------- Mensaje reenviado -------- > Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > Fecha: Fri, 08 Jul 2016 14:16:35 -0700 > De: internet-drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Recommendations for increasing TCP performance in low RTT > networks. > Authors : Marcelo Bagnulo > Koen De Schepper > Glenn Judd > Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt > Pages : 7 > Date : 2016-07-08 > > Abstract: > This documents compiles a set of issues that negatively affect TCP > performance in low RTT networks as well as the recommendations to > overcome them. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 > > > 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/ > > _______________________________________________ > 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 > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Aug 12 12:17:53 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 54A2512DA79 for ; Fri, 12 Aug 2016 12:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9tjw0DVv0J0t for ; Fri, 12 Aug 2016 12:17:39 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABAB712DA77 for ; Fri, 12 Aug 2016 12:17:38 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id x130so22373574ite.1 for ; Fri, 12 Aug 2016 12:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=atQvp5QLu9eHcACWMpKPdIBlW1Saxwbelb4UhU5bfE8=; b=DGgOLleQgI8VI5s9iJbu3gEndOf3QlmOLUTkcykYtb64XZb2hhinVA9JmkXaHdKdUz BDCo5ak7aOBLwz3cn5QHk0FrIShgKNUyqOtSxdVdlXCrCvaaW7rDZFMm+2AsxPS4HiLp 5sYC33V582aeqAD+V+IiharOBKAVb7KMu4HFXR61nYGm2QZq5hBqC+bBkFVeXy/8bDR1 DGL8bo6E4K9+DR+ZOq2b0feZaSgAYZf3mPGp5wJ+1pgEE8uxyetZ1TL1OukV8SWZXAIF /fbVmCmxJuVNmhS5lHxkUKF7k27YdpNj5yEKP4BrKfL+Fw3TXVn19m05C3sWudc8VSUq nt3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=atQvp5QLu9eHcACWMpKPdIBlW1Saxwbelb4UhU5bfE8=; b=MCy63l0sLyEdCB2zPuujxJIkuX81/uyiDEsTThNtSriL0kFB4bCkYPg8Ni7N8MQLYl Sjn/U3W3MCm1LtZ9qFSzTQK4EY1JOAVgvB6JMp7rnl4ZaeNmfXGVJD6So7IwIZiHyH0y y27sds4bNjGaoLA0esqOuo8nxqm1TXT9f8pHWfMMNLCG3pNBtx1z36gjXQeKppzCCigv QulwkqnHavC3SJO1vHTYAPHzjoqqVJALJmTE+MnvSLXVQsaZ2ItjB0fxE8PRXk5OTk/F OZlkwbx7IJsepO+6x0+qafSv3SlBFDCPWe730Be/GvRrqsKn5MVqacMULCGdHx8IwanM c5Bw== X-Gm-Message-State: AEkoouulpbjtyOT2W8K+j+X6ycjPg4qPbY+VZcTeHxQNXNye4C4fwes/JUJhmOP49K0FTGjhTcgtyveOQ+ozqtUE X-Received: by 10.36.150.70 with SMTP id z67mr516444itd.80.1471029450970; Fri, 12 Aug 2016 12:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.244.103 with HTTP; Fri, 12 Aug 2016 12:16:50 -0700 (PDT) In-Reply-To: References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> From: Yuchung Cheng Date: Fri, 12 Aug 2016 12:16:50 -0700 Message-ID: To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: marcelo bagnulo braun , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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, 12 Aug 2016 19:17:40 -0000 On Fri, Aug 12, 2016 at 4:30 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Marcello, > > I very much appreciate your draft. > > Even more so as it addresses one of the things I find to be a bit > "disturbing" in the l4s drafts - Namely the claim that the finer saw > tooth functionality of l4s/DCTCP alone solves the latency problems (while > DCTCP indeed also is tuning the RTO timeout aggressively). > E.g., the formulation in section 1.1 of > https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/?include_t > ext=1 > > It turns out that a TCP algorithm like DCTCP that solves TCP's > scalability problem also solves the latency problem, because the > finer sawteeth cause very little queuing delay. A supporting paper > [DCttH15] gives the full explanation of why the design solves both > the latency and the scaling problems, both in plain English and in > more precise mathematical form. The explanation is summarised > without the maths in [I-D.briscoe-aqm-dualq-coupled]. > > could benefit from a reference to your draft or the issue that you > addresses here (at least for comprehensiveness). > > An additional comment is that new approaches to retransmissions - like > TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at > the moment) might fundamentally alter the picture. I.e., if > retransmissions are sent pro-actively in tail loss situations then more > conservative RTOs may be kept for situations where it is prudent to wait > longer. Don't know if TCP TLP is so widely deployed that it is something > that you should relate to even if it may be superseded by RACK. Just a > thought. TLP and RACK help reduce timeout cases in DC environment for sure. But still it can not completely avoid timeouts. So I agree we should keep timeouts conservative, but the current RFCs are way too conservative: min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. The issue is, the "right" min-RTO depends on the actual DC and stacks: they all have different RTTs and timer granularity. The draft cites Glenn's paper, but Morgan Stanley's DC could be different than others. Other comments on the draft: 1. min ssthresh or cwnd: with very large incast ((tens of) thousands of senders into one receiver), cwnd of 0.1 pkt can still be too big. the only way is to pace the packets over N*RTT intervals. 2. delayed acks: as mentioned the actual time depends a lot on the DC implementation, which is really "vender/owner"-specific. instead of perhaps an option during setup to inform the sender about the max delay in the ack works better. > > BR, Karen > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo > > braun > > Sent: 8. juli 2016 23:19 > > To: tcpm IETF list > > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > > Hi, > > > > We just submitted this draft for consideration of the WG. Comments are > > appreciated. > > > > Regards, marcelo > > > > > > > > > > -------- Mensaje reenviado -------- > > Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > Fecha: Fri, 08 Jul 2016 14:16:35 -0700 > > De: internet-drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Recommendations for increasing TCP > performance in low RTT > > networks. > > Authors : Marcelo Bagnulo > > Koen De Schepper > > Glenn Judd > > Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > Pages : 7 > > Date : 2016-07-08 > > > > Abstract: > > This documents compiles a set of issues that negatively affect TCP > > performance in low RTT networks as well as the recommendations to > > overcome them. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 > > > > > > 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/ > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Aug 12 12:40:44 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 E661412D972 for ; Fri, 12 Aug 2016 12:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 shOBytjMA9ZF for ; Fri, 12 Aug 2016 12:40:38 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EF512D853 for ; Fri, 12 Aug 2016 12:40:38 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id q128so45247677wma.1 for ; Fri, 12 Aug 2016 12:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=p4un+84blmidMyNts2jWdQdqsHoWYebNr4FeqtYg8PQ=; b=ovpKTWA0iWdtTbZhaNyRvDwFLtOf9XJPLSnpgsrK3VZEznsPacQK+oTPerlAwJwxSC N3IDZgP2ZEsQNMMO9DcmWNCf0Wc59BAwA6HhSPZaY2PYckFfT0HMZb86o+oQYgjW+I9G GnLrVx0zHO/nE+KsVG9NdvFPy+fJ/7qCYOASHYAgmSZn1VvnYjIs7ZlKdZAmjFUkf1ba 1lNCWlBNWl1A7MHtqKjcn+KEiXL9YMGN3Ss77s6AFJOCDa93O5HahfFMa0SVMzLdgmK2 ZCatwc2tr94xrMdd2yjK5xHXetdKyIS05RfuMlGN4IpkAAdMDpnSROdXp/F2JfZhRfgp zfkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=p4un+84blmidMyNts2jWdQdqsHoWYebNr4FeqtYg8PQ=; b=bL00khUXvny9QAzXnK2Gp6Q8E80NmbynTw3oHSNse0wnZgn9RlfiMdOQHU2RBHqQbg qoVgyMsKguooOX7cg8EUeeJwsh1XN0iV/O7Y3T6WCC3pzC1DP4BPAGb2QvMF9RGnu4Vo pChMK9hMZX3pj0+UfuPl49tVUk9/UpGtYeVJER0mMJ6Rc+pmy+i2s96qsGFuXS1NUjA/ V5929km8kC0N//9sty5RxGMFWJmL+hkcjU4+7oDpHebx1/sst4aLI0BzrYWaOjGqaMH2 vvACk/RN3Fmr9i0zT2Q1e6AqMzaFjrzjsOxfVApdQ3k/2gCNItTE1LKAfLwQBlFcV9qo 34vw== X-Gm-Message-State: AEkoousM8I02YUlvWJdNu+08W3zvpA618+5IV/s94kHNN0+JWBWN21lYknBs15CLGdfI0kQ3 X-Received: by 10.28.50.199 with SMTP id y190mr489145wmy.61.1471030836637; Fri, 12 Aug 2016 12:40:36 -0700 (PDT) Received: from Macintosh-6.local (av2-84-91-226-53.netvisao.pt. [84.91.226.53]) by smtp.gmail.com with ESMTPSA id ko7sm8800640wjc.48.2016.08.12.12.40.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 12:40:35 -0700 (PDT) To: Yuchung Cheng , Karen Elisabeth Egede Nielsen References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> From: marcelo bagnulo braun Message-ID: <5e5d0f96-9094-689e-8104-40ba48a6692b@it.uc3m.es> Date: Fri, 12 Aug 2016 21:40:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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, 12 Aug 2016 19:40:43 -0000 Karen, Yuchung, Thanks for the comments. Replies below. El 12/08/16 a las 21:16, Yuchung Cheng escribió: > On Fri, Aug 12, 2016 at 4:30 AM, Karen Elisabeth Egede Nielsen > wrote: >> Hi Marcello, >> >> I very much appreciate your draft. >> >> Even more so as it addresses one of the things I find to be a bit >> "disturbing" in the l4s drafts - Namely the claim that the finer saw >> tooth functionality of l4s/DCTCP alone solves the latency problems (while >> DCTCP indeed also is tuning the RTO timeout aggressively). >> E.g., the formulation in section 1.1 of >> https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/?include_t >> ext=1 >> >> It turns out that a TCP algorithm like DCTCP that solves TCP's >> scalability problem also solves the latency problem, because the >> finer sawteeth cause very little queuing delay. A supporting paper >> [DCttH15] gives the full explanation of why the design solves both >> the latency and the scaling problems, both in plain English and in >> more precise mathematical form. The explanation is summarised >> without the maths in [I-D.briscoe-aqm-dualq-coupled]. >> >> could benefit from a reference to your draft or the issue that you >> addresses here (at least for comprehensiveness). >> >> An additional comment is that new approaches to retransmissions - like >> TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at >> the moment) might fundamentally alter the picture. I.e., if >> retransmissions are sent pro-actively in tail loss situations then more >> conservative RTOs may be kept for situations where it is prudent to wait >> longer. Don't know if TCP TLP is so widely deployed that it is something >> that you should relate to even if it may be superseded by RACK. Just a >> thought. > TLP and RACK help reduce timeout cases in DC environment for sure. But > still it can not completely avoid timeouts. So I agree we should keep > timeouts conservative, but the current RFCs are way too conservative: > min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. > > The issue is, the "right" min-RTO depends on the actual DC and stacks: > they all have different RTTs and timer granularity. The draft cites > Glenn's paper, but Morgan Stanley's DC could be different than others. > Right. I guess we should could say that the min RTO should be in the order of the RTT of the considered network when there is zero queueng delay. But if the draft is aiming to be a reccomendation for imeplenters of DC network TCP stacks, then i guess it should provide a guidance that is independent of the DC network itself, since the implementation should work for a variety of DC networks, no? I guess the more general question is whether we need this document i.e. a document describing reccoemndation about how to set TCP for low RTT networks. If people think it is a good idea to have such a document, we then figure how if this is > Other comments on the draft: > > 1. min ssthresh or cwnd: with very large incast ((tens of) thousands > of senders into one receiver), cwnd of 0.1 pkt can still be too big. the > only way is to pace the packets over N*RTT intervals. > Right, If i understood correctly Bob's paper (cited in the draft) this is exactly what they are proposing. I dont think this document is the right place to define the behaviour of CWND less than 1 MSS. I think this should be done in a separated document, which is then referred by the low-rtt draft. Are you aware of other documents (draft or papers others than the one from Bob) describing mechanisms to achieve this? > 2. delayed acks: > as mentioned the actual time depends a lot on the DC implementation, > which is really "vender/owner"-specific. instead of perhaps an option > during setup to inform the sender about the max delay in the ack works > better. > I am not sure if a follow. What is the benefit of allowing dynamic negotiation of the delay ack time? Thanks, marcelo > >> BR, Karen >> >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo >>> braun >>> Sent: 8. juli 2016 23:19 >>> To: tcpm IETF list >>> Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt >>> >>> Hi, >>> >>> We just submitted this draft for consideration of the WG. Comments are >>> appreciated. >>> >>> Regards, marcelo >>> >>> >>> >>> >>> -------- Mensaje reenviado -------- >>> Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt >>> Fecha: Fri, 08 Jul 2016 14:16:35 -0700 >>> De: internet-drafts@ietf.org >>> Responder a: internet-drafts@ietf.org >>> Para: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> >>> Title : Recommendations for increasing TCP >> performance in low RTT >>> networks. >>> Authors : Marcelo Bagnulo >>> Koen De Schepper >>> Glenn Judd >>> Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt >>> Pages : 7 >>> Date : 2016-07-08 >>> >>> Abstract: >>> This documents compiles a set of issues that negatively affect TCP >>> performance in low RTT networks as well as the recommendations to >>> overcome them. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> 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 >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Aug 12 12:51:48 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 D3F3912DA93 for ; Fri, 12 Aug 2016 12:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 at3LQLRLjXOU for ; Fri, 12 Aug 2016 12:51:41 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C70B12DA7F for ; Fri, 12 Aug 2016 12:51:41 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q83so34106906iod.1 for ; Fri, 12 Aug 2016 12:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sWnygOL5qe+EkDikO78f4hdLR9aOs/np/u3uoJeefpM=; b=c3XQXGc74jL+1nQDhtxrJFd1OtoOcuUOtRrbPl9PIm+YNIfPVQ3sdnDMvsRo0OGQU8 Er0bSWR7tMusAkPNNnlDVd7vU1eoi7xyS+SEksjpdl28gwaq68/hoMxmh0yuL3/hX86i 9egD+5fLV9YEjeZbWEghZgfI/kmEYv9Z1IuNeuY1xqKIWzjMI8Pupb9MFOq/n76YEPgn 6G6pZ9XAxEykRIaqv9HQqzOrJH/GG5hk1u4sRdnZCKkApQ8p+vvQ2O7dgx3AVdcRVVXC SwgYNREWkOYzTMCg7w8bGTvStZ7JHX4AFc8ZwFftVWeIydDjlAFXvqyuuPhaK3tVQeZJ sCoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sWnygOL5qe+EkDikO78f4hdLR9aOs/np/u3uoJeefpM=; b=UZBgFS8iHsGOGHJhaO67SyAEGmoNAAti0qOgRvLlyAEu3Bdy2EHZzART9lN5MpYBni IBvFxP4LMbGV6cLT1h1wBWWGsNBGoEFapISP2hKd62yXvj0vP2HiPVdp2e3zEU9fyksb dj8Lc+3ezVebXmxbgh1u0Llfz2HLePrq/KRM+8u1GVPFHQyEV8S9vFe7fXAHQD7s/Pm1 klpLqZUcWsJKROO0fNw0G4+YLlt+OmRFBYKMPuz0c/K3PbXIoaRad1SYOmWzXu61HiUs f+LhScqw3oojkPjebJV9Kh48RgV+vIoCrUB2G7+f4dWMJPdfiWOArlfI5J7qV7m3UWYq w66A== X-Gm-Message-State: AEkoouunf71s/WMxB2HF3dtyGyf/b+163t6FQlbJkXe9aNbdc8ydMUQLF7dYkbDsCI9fdyQslbmWNeOvcPrKEMjJ X-Received: by 10.107.201.135 with SMTP id z129mr22528293iof.114.1471031500135; Fri, 12 Aug 2016 12:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.244.103 with HTTP; Fri, 12 Aug 2016 12:50:59 -0700 (PDT) In-Reply-To: <5e5d0f96-9094-689e-8104-40ba48a6692b@it.uc3m.es> References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> <5e5d0f96-9094-689e-8104-40ba48a6692b@it.uc3m.es> From: Yuchung Cheng Date: Fri, 12 Aug 2016 12:50:59 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Karen Elisabeth Egede Nielsen , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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, 12 Aug 2016 19:51:44 -0000 On Fri, Aug 12, 2016 at 12:40 PM, marcelo bagnulo braun wrote: > Karen, Yuchung, > Thanks for the comments. > Replies below. > > > El 12/08/16 a las 21:16, Yuchung Cheng escribi=C3=B3: > >> On Fri, Aug 12, 2016 at 4:30 AM, Karen Elisabeth Egede Nielsen >> wrote: >>> >>> Hi Marcello, >>> >>> I very much appreciate your draft. >>> >>> Even more so as it addresses one of the things I find to be a bit >>> "disturbing" in the l4s drafts - Namely the claim that the finer saw >>> tooth functionality of l4s/DCTCP alone solves the latency problems (whi= le >>> DCTCP indeed also is tuning the RTO timeout aggressively). >>> E.g., the formulation in section 1.1 of >>> >>> https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/?includ= e_t >>> ext=3D1 >>> >>> It turns out that a TCP algorithm like DCTCP that solves TCP's >>> scalability problem also solves the latency problem, because the >>> finer sawteeth cause very little queuing delay. A supporting paper >>> [DCttH15] gives the full explanation of why the design solves both >>> the latency and the scaling problems, both in plain English and in >>> more precise mathematical form. The explanation is summarised >>> without the maths in [I-D.briscoe-aqm-dualq-coupled]. >>> >>> could benefit from a reference to your draft or the issue that you >>> addresses here (at least for comprehensiveness). >>> >>> An additional comment is that new approaches to retransmissions - like >>> TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at >>> the moment) might fundamentally alter the picture. I.e., if >>> retransmissions are sent pro-actively in tail loss situations then more >>> conservative RTOs may be kept for situations where it is prudent to wai= t >>> longer. Don't know if TCP TLP is so widely deployed that it is somethin= g >>> that you should relate to even if it may be superseded by RACK. Just a >>> thought. >> >> TLP and RACK help reduce timeout cases in DC environment for sure. But >> still it can not completely avoid timeouts. So I agree we should keep >> timeouts conservative, but the current RFCs are way too conservative: >> min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. >> >> The issue is, the "right" min-RTO depends on the actual DC and stacks: >> they all have different RTTs and timer granularity. The draft cites >> Glenn's paper, but Morgan Stanley's DC could be different than others. >> > > Right. > > I guess we should could say that the min RTO should be in the order of th= e > RTT of the considered network when there is zero queueng delay. > But if the draft is aiming to be a reccomendation for imeplenters of DC > network TCP stacks, then i guess it should provide a guidance that is > independent of the DC network itself, since the implementation should wor= k > for a variety of DC networks, no? > > > I guess the more general question is whether we need this document i.e. a > document describing reccoemndation about how to set TCP for low RTT > networks. If people think it is a good idea to have such a document, we t= hen > figure how if this is my conundrum is that DC tcp stuff is usually not an inter-op issue for the Internet so this draft is more of a "how to tune your DC tcp stack". but I can be convinced either ways. > >> Other comments on the draft: >> >> 1. min ssthresh or cwnd: with very large incast ((tens of) thousands >> of senders into one receiver), cwnd of 0.1 pkt can still be too big. the >> only way is to pace the packets over N*RTT intervals. >> > Right, If i understood correctly Bob's paper (cited in the draft) this is > exactly what they are proposing. > I dont think this document is the right place to define the behaviour of > CWND less than 1 MSS. I think this should be done in a separated document= , > which is then referred by the low-rtt draft. > > Are you aware of other documents (draft or papers others than the one fro= m > Bob) describing mechanisms to achieve this? > >> 2. delayed acks: >> as mentioned the actual time depends a lot on the DC implementation, >> which is really "vender/owner"-specific. instead of perhaps an option >> during setup to inform the sender about the max delay in the ack works >> better. >> > I am not sure if a follow. > What is the benefit of allowing dynamic negotiation of the delay ack time= ? > Thanks, marcelo the receiver may decide to delay ack up to certain time. it could be based on DC implementation or host limit. It'd be good for sender to learn about that to adapt his RTO. For example, say it's a cloud VM. VM of OS1 may use a max delay for d-ack say 2ms. but VM of OS2 may use 40ms. The lack of such information makes the sender to these VMs use something conservative of known max of all, otherwise he risks spurious RTOs. > > > > >> >>> BR, Karen >>> >>>> -----Original Message----- >>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo >>>> braun >>>> Sent: 8. juli 2016 23:19 >>>> To: tcpm IETF list >>>> Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt >>>> >>>> Hi, >>>> >>>> We just submitted this draft for consideration of the WG. Comments are >>>> appreciated. >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>> -------- Mensaje reenviado -------- >>>> Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt >>>> Fecha: Fri, 08 Jul 2016 14:16:35 -0700 >>>> De: internet-drafts@ietf.org >>>> Responder a: internet-drafts@ietf.org >>>> Para: i-d-announce@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> >>> directories. >>>> >>>> >>>> Title : Recommendations for increasing TCP >>> >>> performance in low RTT >>>> >>>> networks. >>>> Authors : Marcelo Bagnulo >>>> Koen De Schepper >>>> Glenn Judd >>>> Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt >>>> Pages : 7 >>>> Date : 2016-07-08 >>>> >>>> Abstract: >>>> This documents compiles a set of issues that negatively affect TC= P >>>> performance in low RTT networks as well as the recommendations to >>>> overcome them. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> >> > From nobody Fri Aug 12 13:35:49 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 44E7612DA96; Fri, 12 Aug 2016 13:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 wWzErIqYppEr; Fri, 12 Aug 2016 13:35:46 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0108.outbound.protection.outlook.com [104.47.41.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A966212DAB1; Fri, 12 Aug 2016 13:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9NcYhyERbF57EMrvaxLFccBxCiluk5LSqAfi86+kiRE=; b=EI/oWmSp8tvL6NOeb+mm+AN+dzREdaD8Z0WhkZFmRZxB3kFQ1g0qyg0DO2haSeKIXsleFbS9pIgtvYCghQRAUN0OQAzjIHhaiutOJb05zCIP4NTlwda2FJ6ftod8KOpBG1VyTyH1Pnj36drsnO4LlY3W1OoWAK+6U+eA1uIm2Wc= Received: from BLUPR03MB004.namprd03.prod.outlook.com (10.255.208.38) by BLUPR03MB001.namprd03.prod.outlook.com (10.255.208.35) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.544.10; Fri, 12 Aug 2016 20:35:41 +0000 Received: from BLUPR03MB004.namprd03.prod.outlook.com ([169.254.2.30]) by BLUPR03MB004.namprd03.prod.outlook.com ([169.254.2.30]) with mapi id 15.01.0557.021; Fri, 12 Aug 2016 20:35:40 +0000 From: Praveen Balasubramanian To: Yuchung Cheng , Karen Elisabeth Egede Nielsen Thread-Topic: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt Thread-Index: AQHR9M4ywbpExZthr0er6u5O8CZMX6BFxyYA Date: Fri, 12 Aug 2016 20:35:40 +0000 Message-ID: References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> In-Reply-To: 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=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:4::584] x-ms-office365-filtering-correlation-id: b584871a-10e7-48c9-56d7-08d3c2f039e5 x-ms-office365-filtering-ht: Tenant x-microsoft-exchange-diagnostics: 1; BLUPR03MB001; 6:hoKvihImVq4lnNHg4LkA81A2grR0WNtg1f3/Zf8ITGEAnTHxXFLfSAe8N5B41WmhGzsV8PK/cN1AHe6hLw0VmibEvufWwgNIvSd7LnZJVungnfI9WVzlZmcBxlP6zpUpW1roufWB6g9Wi2EmpiVfQvmvQmQhMx+a9l/+pilSHrjPsbk+d5uFbHom3rBBkTCnBKL5dQmOuu0psOk4j7e4ANry5XVgdB/ruxQKTBrrz1/76pzamEs3m/5JB+KqCEp8EcObBwyJ0QYZ0JHXB8xITiajqughH2jFs9Kky44TyCSt+GDD0m42S3WbxlHVk+K6qvbPi0COTquDzxJ85AXH8A==; 5:+88adDQbdb4zvuYCR4TdNPFS+81sUp5zMHgh0CPPRu+hJch6YQnJbphIrjByKH3kjt1LpTIdOWigvVdKoIOB4BMONqkbNyfHqJLsY/bhhC1/WcbCuSgdy0wRjIeBV6e0imjgX1Yc4CRHO+l/OuP79/anNK75OimU9Vap2ciqkdw=; 24:vJpqa696B16ZXlB6mRX5WUFcYgmi/POMVU4yoopK/YdLDuTz6k2c63kLCYY1MLOkmNHcsARpk/n5npguYeLpNFUxgR04P3H83JcTn2fg0Zk=; 7:+5aoddz1iIrtyuSN9nRBy/+Xm3eU7++NLiwxHVrf1PP+nKWu064efKmHM7ragx9cltmVRmpHpE1xvKR4ynAxnFkUS9PSllM+EgqR7OGlfphHETNg+QIKPlYsBs3yN1mYh2z0ZulRgHLZRpZOjL5gf0/qE9Il9Vu4Oecn36rhAADVJK49JihQCtkgnAJVdQ7Ktwg+9zbBtBH5TGt/la7OBeUXVwP2CAVFjkNX4O95rGbfBLXcP4x6gVmE6s6BfpUr x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB001; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BLUPR03MB001; BCL:0; PCL:0; RULEID:(304825118); SRVR:BLUPR03MB001; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(76094002)(377454003)(377424004)(199003)(2473001)(13464003)(24454002)(68736007)(586003)(97736004)(189998001)(2906002)(8990500004)(5002640100001)(87936001)(93886004)(2900100001)(2950100001)(76576001)(105586002)(5001770100001)(9686002)(6116002)(81156014)(7846002)(81166006)(102836003)(4326007)(8936002)(7736002)(7696003)(8676002)(101416001)(106356001)(106116001)(54356999)(76176999)(86362001)(50986999)(19580395003)(10090500001)(92566002)(19580405001)(305945005)(74316002)(5005710100001)(33656002)(15975445007)(10290500002)(122556002)(99286002)(3660700001)(10400500002)(86612001)(3280700002)(230783001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB001; H:BLUPR03MB004.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 20:35:40.7032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB001 Archived-At: Cc: tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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, 12 Aug 2016 20:35:48 -0000 >>2. delayed acks: as mentioned the actual time depends a lot on the DC implementation, which = is really "vender/owner"-specific. instead of perhaps an option during setu= p to inform the sender about the max delay in the ack works better. Yeah this is a real problem in IaaS environment today since TCP sender pick= s minrto and receiver picks delayed ACK timeout independently and can cause= spurious RTOs if the minrto is too aggressive. Windows server tries to use= the connection handshake RTT (< 10 msec) to auto pick the DC values but th= is is a heuristic that can fail and doesn't really work in the Linux intero= p cases.=20 -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng Sent: Friday, August 12, 2016 12:17 PM To: Karen Elisabeth Egede Nielsen Cc: tcpm IETF list ; TCP Prague List Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt On Fri, Aug 12, 2016 at 4:30 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Marcello, > > I very much appreciate your draft. > > Even more so as it addresses one of the things I find to be a bit=20 > "disturbing" in the l4s drafts - Namely the claim that the finer saw=20 > tooth functionality of l4s/DCTCP alone solves the latency problems=20 > (while DCTCP indeed also is tuning the RTO timeout aggressively). > E.g., the formulation in section 1.1 of=20 > https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/?inclu > de_t > ext=3D1 > > It turns out that a TCP algorithm like DCTCP that solves TCP's > scalability problem also solves the latency problem, because the > finer sawteeth cause very little queuing delay. A supporting paper > [DCttH15] gives the full explanation of why the design solves both > the latency and the scaling problems, both in plain English and in > more precise mathematical form. The explanation is summarised > without the maths in [I-D.briscoe-aqm-dualq-coupled]. > > could benefit from a reference to your draft or the issue that you=20 > addresses here (at least for comprehensiveness). > > An additional comment is that new approaches to retransmissions -=20 > like TCP TLP and TCP RACK (also SCTP TLR which however is not=20 > progressing at the moment) might fundamentally alter the picture.=20 > I.e., if retransmissions are sent pro-actively in tail loss situations=20 > then more conservative RTOs may be kept for situations where it is=20 > prudent to wait longer. Don't know if TCP TLP is so widely deployed=20 > that it is something that you should relate to even if it may be=20 > superseded by RACK. Just a thought. TLP and RACK help reduce timeout cases in DC environment for sure. But stil= l it can not completely avoid timeouts. So I agree we should keep timeouts = conservative, but the current RFCs are way too conservative: min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. The issue is, the "right" min-RTO depends on the actual DC and stacks: they all have different RTTs and timer granularity. The draft cites Glenn's= paper, but Morgan Stanley's DC could be different than others. Other comments on the draft: 1. min ssthresh or cwnd: with very large incast ((tens of) thousands of sen= ders into one receiver), cwnd of 0.1 pkt can still be too big. the only way= is to pace the packets over N*RTT intervals. 2. delayed acks: as mentioned the actual time depends a lot on the DC implementation, which = is really "vender/owner"-specific. instead of perhaps an option during setu= p to inform the sender about the max delay in the ack works better. > > BR, Karen > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo=20 > > bagnulo braun > > Sent: 8. juli 2016 23:19 > > To: tcpm IETF list > > Subject: [tcpm] Fwd: I-D Action:=20 > > draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > > Hi, > > > > We just submitted this draft for consideration of the WG. Comments=20 > > are appreciated. > > > > Regards, marcelo > > > > > > > > > > -------- Mensaje reenviado -------- > > Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > Fecha: Fri, 08 Jul 2016 14:16:35 -0700 > > De: internet-drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Recommendations for increasing TCP > performance in low RTT > > networks. > > Authors : Marcelo Bagnulo > > Koen De Schepper > > Glenn Judd > > Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > Pages : 7 > > Date : 2016-07-08 > > > > Abstract: > > This documents compiles a set of issues that negatively affect TCP > > performance in low RTT networks as well as the recommendations to > > overcome them. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 > > > > > > 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/ > > > > _______________________________________________ > > 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=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Aug 15 02:00:45 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 8046C12B051 for ; Mon, 15 Aug 2016 02:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 GbotRnXjuC3x for ; Mon, 15 Aug 2016 02:00:38 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE4612D0A5 for ; Mon, 15 Aug 2016 02:00:35 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id b62so74922574iod.3 for ; Mon, 15 Aug 2016 02:00:35 -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; bh=bW/cl1L/5rIdSFG7oqVz3C6vbUO5QPH1OdO76PBz8WU=; b=1bXYT2Ru9iH8MVr+DBd14UHeUknksiQeYhy4mRiLl7VkpQm0mDxU0bzUDjv+bYhidv Lln+NtchRFlTLY5LK44XngBV0inpbdcBElAz1mH63bG4+RijavEEUHztmFMwKoFIz0Gq SvCEQOO27GyvTgSZc1fwwJd9uFkpQj4bikhVU= 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; bh=bW/cl1L/5rIdSFG7oqVz3C6vbUO5QPH1OdO76PBz8WU=; b=gQsZpzkBRwd6TI29kH3oeMosBE8CQ9/7d2RhXkFx1YNhMaWPs7NEsP4Zl8F55RVQgj SBrypWgRxAUMBjJHIt56OYLYWq7e/jECBFTrku20Fl7z0WltiWZCXPMweTTbaP1wELsy GzBVVNmnjKs5NwRr8dL84c2g7871bjVz5NjZo/TML0Hj7NT4jd3JhBuPpZl5kpW0t0v5 MU2A1PrZ2VMCZbHQS5vNY7eJfFGEhkBCTxay+CsWqsMRH2I4k7ayKCQWKHM7uktdn0Lx TRqBknx8pFxZ4AB/nad6EOX4uhnAEU+UoAFm1lUkrBbKapVVPHtHZS8TLSwhz1XMiKNH fLhw== X-Gm-Message-State: AEkoout2wI2c6YCoXHSb0iSj9ty4FJltBglNlSGL3X7uUp9AUOXZgrFZh1wO6QXGP4Hj4z0VmRir/mLrC6r3txMGkOSL3uKFpwc8vQrV2demy2sWOxkUtsW6A59jN5csW7Uj5ZgeHdA6QQ== X-Received: by 10.107.20.82 with SMTP id 79mr30901765iou.108.1471251634349; Mon, 15 Aug 2016 02:00:34 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGd4OoGFyImcsqDlVk0oY8T3VfV3QH845XxAem+5TgCNV3HJ6CA+6qg Date: Mon, 15 Aug 2016 11:00:24 +0200 Message-ID: <623f46dedcc661ae74563f6bf08f46a5@mail.gmail.com> To: Yuchung Cheng Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: marcelo bagnulo braun , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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: Mon, 15 Aug 2016 09:00:41 -0000 Hi Yuchung, > > > > An additional comment is that new approaches to retransmissions - like > > TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at > > the moment) might fundamentally alter the picture. I.e., if > > retransmissions are sent pro-actively in tail loss situations then more > > conservative RTOs may be kept for situations where it is prudent to wait > > longer. Don't know if TCP TLP is so widely deployed that it is something > > that you should relate to even if it may be superseded by RACK. Just a > > thought. > TLP and RACK help reduce timeout cases in DC environment for sure. But > still it can not completely avoid timeouts. [Karen Elisabeth Egede Nielsen] Agreed. For SCTP TLR we still see RTO-timeouts when also probes/retransmissions are lost. I assume that it would be something like this also for Rack/TLP - though potentially depending on how many consecutive probes that are allowed. The role of RTO-timeouts are different when RACK/TLP is enabled and it might be counterproductive to have RTO-timeouts be too aggressive as the function indeed with TLP/RACK becomes something much closer to the original intend (read: how I understand the original intend) - namely to introduce a pause for the network to recover when things are really (consistently) bad. If the RTO is lowered down to be comparable in order of magnitude with the RTT (with some delay_ack considerations) we are narrowing the situation where TLP/RACK probing is able to kick in before RTO-retransmissions starts anyway. I understand that RTOs should be adjusted to the network dynamics, but I do think that it is important to understand - for the DC environment - if the need for the low RTOs in DC's is motivated mainly by having RTO-retransmissions fix the tail loss recovery deficiencies of TCP, which RACK/TLP addresses, or more generally for a need for more timely probe and reactivation for/after network recovery. Or perhaps you see the TLP probe timeout and the RTO timeout eventually being driven by the same timer, the reactions (e.g. CC reactions) then possibly depending on state (probe already sent or not). BR, Karen So I agree we should keep > timeouts conservative, but the current RFCs are way too conservative: > min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. > > The issue is, the "right" min-RTO depends on the actual DC and stacks: > they all have different RTTs and timer granularity. The draft cites > Glenn's paper, but Morgan Stanley's DC could be different than others. > > > Other comments on the draft: > > 1. min ssthresh or cwnd: with very large incast ((tens of) thousands > of senders into one receiver), cwnd of 0.1 pkt can still be too big. the > only way is to pace the packets over N*RTT intervals. > > > 2. delayed acks: > as mentioned the actual time depends a lot on the DC implementation, > which is really "vender/owner"-specific. instead of perhaps an option > during setup to inform the sender about the max delay in the ack works > better. > > > > > > > BR, Karen > > > > > -----Original Message----- > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo > bagnulo > > > braun > > > Sent: 8. juli 2016 23:19 > > > To: tcpm IETF list > > > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > > > > Hi, > > > > > > We just submitted this draft for consideration of the WG. Comments are > > > appreciated. > > > > > > Regards, marcelo > > > > > > > > > > > > > > > -------- Mensaje reenviado -------- > > > Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > Fecha: Fri, 08 Jul 2016 14:16:35 -0700 > > > De: internet-drafts@ietf.org > > > Responder a: internet-drafts@ietf.org > > > Para: i-d-announce@ietf.org > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > Title : Recommendations for increasing TCP > > performance in low RTT > > > networks. > > > Authors : Marcelo Bagnulo > > > Koen De Schepper > > > Glenn Judd > > > Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > Pages : 7 > > > Date : 2016-07-08 > > > > > > Abstract: > > > This documents compiles a set of issues that negatively affect TCP > > > performance in low RTT networks as well as the recommendations to > > > overcome them. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 > > > > > > > > > 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/ > > > > > > _______________________________________________ > > > 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 > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Aug 15 02:03:23 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 D9A3B12D0AF for ; Mon, 15 Aug 2016 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 ckwc8_u5Pryi for ; Mon, 15 Aug 2016 02:03:08 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1D612D0A5 for ; Mon, 15 Aug 2016 02:03:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id m101so74938285ioi.2 for ; Mon, 15 Aug 2016 02:03:08 -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; bh=bW/cl1L/5rIdSFG7oqVz3C6vbUO5QPH1OdO76PBz8WU=; b=XXWHhvmZqCULdFgb81+GNqpMaH6Exgv0QfGkWybkxyQ5QseFYSn8yJDOgWWdJoSOcU b5l7TNtV4jXYyCeBgVI2nDpByLS+MWGrTMYpS5nuE9IxOBOujYOyww1R8NFeR8bHiCXO FTYjEeAdCd5fGwMJYVlOvcfzruYrvHunBUON0= 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; bh=bW/cl1L/5rIdSFG7oqVz3C6vbUO5QPH1OdO76PBz8WU=; b=ZhVxdPaJ2NFZF6lYcAJUN8PGVj10WGtRY6A8mTvRWWCuV0pfniUpVQReS9YjreiCdu dHROXjKvlye664mBP03n4DkC5m4ZS5YJ6u/xD/9WESuYX8Qv8J0EUYsfJa4GeBIY2OCF +QXsaEjpSYaemduJ5hCdMnT1OeI9dVLev46c68Kc68dUkuPfPXln5p9WsOExWsl7LSjb LTk9TB3r4/45bpH2f3FZK51rasQFf/q2hY0YYlGrXOmxtOa4m9lWQawTB8v4Gbz5+DVm kFwkEvliurAnUHtfmrHlxXQneHHmXpFGSlimZxv1YW8fW67iECNY+0taIH62lPKEZhm9 nm+A== X-Gm-Message-State: AEkoout+zoYqFhbs2cQ5/rGuHvRlXfa14886QUVN9Az5leSg66nnia3KNjAjlj/EiiTXBu3ZmDd+G2Wavy+SefH8dbEXw7hDZh8hqIegYlK74yqsyNRtXF+CIWHb1LZrNVUFGXuTR+Z6Gg== X-Received: by 10.107.37.198 with SMTP id l189mr30922932iol.117.1471251782673; Mon, 15 Aug 2016 02:03:02 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGd4OoGFyImcsqDlVk0oY8T3VfV3QH845XxAem+5TgCNV3HJ6CA+6qg Date: Mon, 15 Aug 2016 11:00:24 +0200 Message-ID: <1ed9d8e85fb779cfae5c187eddb2fd8b@mail.gmail.com> To: Yuchung Cheng Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: marcelo bagnulo braun , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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: Mon, 15 Aug 2016 09:03:10 -0000 Hi Yuchung, > > > > An additional comment is that new approaches to retransmissions - like > > TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at > > the moment) might fundamentally alter the picture. I.e., if > > retransmissions are sent pro-actively in tail loss situations then more > > conservative RTOs may be kept for situations where it is prudent to wait > > longer. Don't know if TCP TLP is so widely deployed that it is something > > that you should relate to even if it may be superseded by RACK. Just a > > thought. > TLP and RACK help reduce timeout cases in DC environment for sure. But > still it can not completely avoid timeouts. [Karen Elisabeth Egede Nielsen] Agreed. For SCTP TLR we still see RTO-timeouts when also probes/retransmissions are lost. I assume that it would be something like this also for Rack/TLP - though potentially depending on how many consecutive probes that are allowed. The role of RTO-timeouts are different when RACK/TLP is enabled and it might be counterproductive to have RTO-timeouts be too aggressive as the function indeed with TLP/RACK becomes something much closer to the original intend (read: how I understand the original intend) - namely to introduce a pause for the network to recover when things are really (consistently) bad. If the RTO is lowered down to be comparable in order of magnitude with the RTT (with some delay_ack considerations) we are narrowing the situation where TLP/RACK probing is able to kick in before RTO-retransmissions starts anyway. I understand that RTOs should be adjusted to the network dynamics, but I do think that it is important to understand - for the DC environment - if the need for the low RTOs in DC's is motivated mainly by having RTO-retransmissions fix the tail loss recovery deficiencies of TCP, which RACK/TLP addresses, or more generally for a need for more timely probe and reactivation for/after network recovery. Or perhaps you see the TLP probe timeout and the RTO timeout eventually being driven by the same timer, the reactions (e.g. CC reactions) then possibly depending on state (probe already sent or not). BR, Karen So I agree we should keep > timeouts conservative, but the current RFCs are way too conservative: > min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. > > The issue is, the "right" min-RTO depends on the actual DC and stacks: > they all have different RTTs and timer granularity. The draft cites > Glenn's paper, but Morgan Stanley's DC could be different than others. > > > Other comments on the draft: > > 1. min ssthresh or cwnd: with very large incast ((tens of) thousands > of senders into one receiver), cwnd of 0.1 pkt can still be too big. the > only way is to pace the packets over N*RTT intervals. > > > 2. delayed acks: > as mentioned the actual time depends a lot on the DC implementation, > which is really "vender/owner"-specific. instead of perhaps an option > during setup to inform the sender about the max delay in the ack works > better. > > > > > > > BR, Karen > > > > > -----Original Message----- > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo > bagnulo > > > braun > > > Sent: 8. juli 2016 23:19 > > > To: tcpm IETF list > > > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > > > > Hi, > > > > > > We just submitted this draft for consideration of the WG. Comments are > > > appreciated. > > > > > > Regards, marcelo > > > > > > > > > > > > > > > -------- Mensaje reenviado -------- > > > Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > Fecha: Fri, 08 Jul 2016 14:16:35 -0700 > > > De: internet-drafts@ietf.org > > > Responder a: internet-drafts@ietf.org > > > Para: i-d-announce@ietf.org > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > Title : Recommendations for increasing TCP > > performance in low RTT > > > networks. > > > Authors : Marcelo Bagnulo > > > Koen De Schepper > > > Glenn Judd > > > Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > > Pages : 7 > > > Date : 2016-07-08 > > > > > > Abstract: > > > This documents compiles a set of issues that negatively affect TCP > > > performance in low RTT networks as well as the recommendations to > > > overcome them. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 > > > > > > > > > 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/ > > > > > > _______________________________________________ > > > 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 > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Aug 15 09:50:58 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 CA08512D0DC for ; Mon, 15 Aug 2016 09:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hK3yEiQLcs2t for ; Mon, 15 Aug 2016 09:50:53 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C26612D8B3 for ; Mon, 15 Aug 2016 09:49:54 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f6so47281157ith.0 for ; Mon, 15 Aug 2016 09:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jFbq+qmd924+GMTxXpIpWeGG/lrHFOqdk12Yn0hq4YE=; b=Buub3y2ihWU+aG2sE5NvOkVw+fGseV1CNn3UFwMhmQlHSibAO+0aQyhu1/2GMcOLaY rovmKsqnKr2rpINYOgWOg/Mjhjxmnk10EgvhBWPvDIQiDltc9UoO2M/cC5crIf/xsker N2Teua70ckcLJb5PN06Ehmw25Vh+f+4jYpRg+uU1M/FcVw/iT3hIABCsMGqqo4Y4KR3e VMWVSgw8A1/3aT70DK0bimBR4Np06zCcJ7CQbzcWXIB0TH26GVmcRCCJTmPr5uR6WnNM +YOBjh7FR6MdCrPer71xzv6vHengBkRXl67ruxmDOcJBXeFA98RR2H/fmCPe/SA6kANv 0AkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jFbq+qmd924+GMTxXpIpWeGG/lrHFOqdk12Yn0hq4YE=; b=gLs7Spw3EyQOMfrDuztXGOQdvW3yJyoQHg1yX1I2x65gM6XxV1cLQ96T91rSyBB8wN uolZW1GZCqw7e8XtA+HOn9kjMMZkUPNJHNEqNC19GJaiUTwZx3q5P45pgixMwgS9J3N8 apFuhqzC+EgU0PbpryhaRcKorL0DA31d5oK1u1KfyJ0EkzKKIFvdJZpSOQz3HTJzrt5n H/xG/jkGk5LP0IsBRxJB700/JBitdUVB5ZIauHVyyuRAPbrzEa3rJxOFmLg3TpnHN3Nv ezJwsH8RobDgwqBNKu1uW2tccfgRernVO74GEvYEuiMtA0YVxnmfCZ6VCGEEfWDk96xf j+kQ== X-Gm-Message-State: AEkoouvKzBYY00lISrvYQmWFwG/dui3TWxMOFTWe46fzrRqiI/63Z3//rU63B+GDGz9gzsFKY8wykUgkVkGVN8uS X-Received: by 10.36.82.81 with SMTP id d78mr14561037itb.65.1471279793306; Mon, 15 Aug 2016 09:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.244.103 with HTTP; Mon, 15 Aug 2016 09:49:12 -0700 (PDT) In-Reply-To: <623f46dedcc661ae74563f6bf08f46a5@mail.gmail.com> References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> <623f46dedcc661ae74563f6bf08f46a5@mail.gmail.com> From: Yuchung Cheng Date: Mon, 15 Aug 2016 09:49:12 -0700 Message-ID: To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: marcelo bagnulo braun , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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: Mon, 15 Aug 2016 16:50:55 -0000 On Mon, Aug 15, 2016 at 2:00 AM, Karen Elisabeth Egede Nielsen wrote: > Hi Yuchung, > >> > >> > An additional comment is that new approaches to retransmissions - like >> > TCP TLP and TCP RACK (also SCTP TLR which however is not progressing at >> > the moment) might fundamentally alter the picture. I.e., if >> > retransmissions are sent pro-actively in tail loss situations then more >> > conservative RTOs may be kept for situations where it is prudent to wait >> > longer. Don't know if TCP TLP is so widely deployed that it is something >> > that you should relate to even if it may be superseded by RACK. Just a >> > thought. >> TLP and RACK help reduce timeout cases in DC environment for sure. But >> still it can not completely avoid timeouts. > > [Karen Elisabeth Egede Nielsen] Agreed. > > For SCTP TLR we still see RTO-timeouts when also probes/retransmissions are > lost. > I assume that it would be something like this also for Rack/TLP - though > potentially depending on how many consecutive probes that are allowed. > The role of RTO-timeouts are different when RACK/TLP is enabled and it might > be counterproductive to have RTO-timeouts be too aggressive as the function > indeed with TLP/RACK becomes something much closer to the original intend > (read: how I understand the original intend) - namely to introduce a pause > for the network to recover when things are really (consistently) bad. > > If the RTO is lowered down to be comparable in order of magnitude with the > RTT (with some delay_ack considerations) we are narrowing the situation > where TLP/RACK probing is able to kick in before RTO-retransmissions starts > anyway. > > I understand that RTOs should be adjusted to the network dynamics, but I do > think that it is important to understand - for the DC environment - if the > need for the low RTOs in DC's is > motivated mainly by having RTO-retransmissions fix the tail loss recovery > deficiencies of TCP, which RACK/TLP addresses, or more generally for a need > for more timely probe and reactivation for/after network recovery. > > Or perhaps you see the TLP probe timeout and the RTO timeout eventually > being driven by the same timer, the reactions (e.g. CC reactions) then > possibly depending on state (probe already sent or not). I agree with your thought here. More generally, I'd like to evolve the state of art recovery with these principles: 1. React with ack events as much as possible 2. Send tiny probes to trigger (1) after 2-3 RTTs 3. Have conservative RTOs that (exp-backoff) expire at an order of RTT to repair the head for reliability. On thing about RTO: RTO current reset cwnd to 1 upon firing no matter what. We should ONLY reset cwnd to 1 if no news (acks/data) for a long duration. This is quite important for performance: today cwnd is reset to 1 even if every packet but the first one has been recently delivered. This unnecessarily conservative because the ack clock isn't lost yet. But the collateral damage to performance is huge on large BDP networks. This results work-arounds to shorten and avoid RTOs. I'd like to address these points in the upcoming RACK/TLP draft. > > BR, Karen > > So I agree we should keep >> timeouts conservative, but the current RFCs are way too conservative: >> min RTO of 1 second is 4-5 orders of magnitude of DC RTTs. >> >> The issue is, the "right" min-RTO depends on the actual DC and stacks: >> they all have different RTTs and timer granularity. The draft cites >> Glenn's paper, but Morgan Stanley's DC could be different than others. >> >> >> Other comments on the draft: >> >> 1. min ssthresh or cwnd: with very large incast ((tens of) thousands >> of senders into one receiver), cwnd of 0.1 pkt can still be too big. the >> only way is to pace the packets over N*RTT intervals. >> >> >> 2. delayed acks: >> as mentioned the actual time depends a lot on the DC implementation, >> which is really "vender/owner"-specific. instead of perhaps an option >> during setup to inform the sender about the max delay in the ack works >> better. >> >> >> >> > >> > BR, Karen >> > >> > > -----Original Message----- >> > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo >> bagnulo >> > > braun >> > > Sent: 8. juli 2016 23:19 >> > > To: tcpm IETF list >> > > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt >> > > >> > > Hi, >> > > >> > > We just submitted this draft for consideration of the WG. Comments are >> > > appreciated. >> > > >> > > Regards, marcelo >> > > >> > > >> > > >> > > >> > > -------- Mensaje reenviado -------- >> > > Asunto: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt >> > > Fecha: Fri, 08 Jul 2016 14:16:35 -0700 >> > > De: internet-drafts@ietf.org >> > > Responder a: internet-drafts@ietf.org >> > > Para: i-d-announce@ietf.org >> > > >> > > >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > > >> > > >> > > Title : Recommendations for increasing TCP >> > performance in low RTT >> > > networks. >> > > Authors : Marcelo Bagnulo >> > > Koen De Schepper >> > > Glenn Judd >> > > Filename : draft-bagnulo-tcpm-tcp-low-rtt-00.txt >> > > Pages : 7 >> > > Date : 2016-07-08 >> > > >> > > Abstract: >> > > This documents compiles a set of issues that negatively affect TCP >> > > performance in low RTT networks as well as the recommendations to >> > > overcome them. >> > > >> > > >> > > The IETF datatracker status page for this draft is: >> > > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/ >> > > >> > > There's also a htmlized version available at: >> > > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00 >> > > >> > > >> > > 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/ >> > > >> > > _______________________________________________ >> > > 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 >> > > >> > > >> > > _______________________________________________ >> > > tcpm mailing list >> > > tcpm@ietf.org >> > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Aug 17 23:47:15 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 55C4A12D0C0; Wed, 17 Aug 2016 23:47:09 -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 xICn47kdbOUI; Wed, 17 Aug 2016 23:47:05 -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 CC791126579; Wed, 17 Aug 2016 23:47:04 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-36-57b559e611c2 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 25.23.02553.6E955B75; Thu, 18 Aug 2016 08:47:03 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 18 Aug 2016 08:47:02 +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=WX8cQB7ORv59Dx8QddbBSpuWrFC7SsiKL4JIhc8Hnz8=; b=dpwXnbQX68M/bAm06YhIIRjA1qMkwRq2rnRXwmuCUFhZCfNrmzPbo6UGpZm7wl/LyDWr0HOAvHqOOk80oqwn1PsoxbQpSXFsWRm1J0rQxQkuKK9om1BbKi7WNzo2GFq0o5rB0f25WV1ITcA3En/7+Ld3Js644P4DWGwrA0E2akM= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Thu, 18 Aug 2016 06:46:59 +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.009; Thu, 18 Aug 2016 06:46:59 +0000 From: Ingemar Johansson S To: "csp@csperkins.org" , "ietf@bobbriscoe.net" , "tsvwg-chairs@tools.ietf.org" Thread-Topic: [tcpPrague] Impact of an L4S experiment on non-TCP transport using ECT(1) Thread-Index: AdH5G2c9J8/GxOnSTRCcozal+HM+jA== Date: Thu, 18 Aug 2016 06:46:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-office365-filtering-correlation-id: c12704d6-911b-4eaa-5bd8-08d3c7337452 x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:EJBWOLJIL0LSlSswW8onD2fNN1lmec/fIV4KcAXiut4igmenT4ODANrYn9WaHdlJaunGIoZHzmGrObiRiWIZmLOxoP8KvsqtIkBzlc8NPre+G8tCyiKzvSrHYKGxn47bk/oWnViiDKaAhomtN7cpJcG72VWvUGkbScR7tevJmSpw0lcL7MX2Cpaiv6QOiSTXk/DuSrv29QUh1mwHAmKtPycjUWV8Oq1ses90cge/3p+QaP0yB+ZxWhkNp9/gCf3khR0biZasdO14LsymZnUm0Bne5q2CQrR1WudA6OaIrEQ=; 5:qftBUftdP5DX4j7MZzBABrO7y3x6vvYHUikWV0BmlnAGDHFBj4VPJ04aF4M/bkF1riBmmhtYRToFkIjuFuwrWvvTXzsx6XpVP66QjsSku5eT+fDJySMCFOEW4tt/8pAyFUA0b2vbtP7MW6Pwu9kNiQ==; 24:Ui3ixuE2hdjBgWMTBZGPzT9AjGch3uMOaRNE6rsdCnDwJEzx1PXfVeYs1D5TrtsA3OY8DvtOko8Fru8UA9dQF1DEHZSHW40tStZAj58Lg9k=; 7:73IBPAfsPW9grDwlLA6uck4/mi0wdkMx+jM9YUuTxV4mBYFbWkqHBld5OqdEDuI8cUzPK8AYmBM6hSWf2+bhpH7/e3UUQ7yBumbvEXKM5QmVSlT19hGLkqWZB4ORkh59q+sBMFv8VMxGYhfxNO7iU96uXRzbPBv6CjS66gbHMoex/5+hhPGXtO2Ohm31LcKn2VCgnTKfk6MIdLOhPgj+ZK9Je0t/AmcKaJq/A3CKH+/gQ5F7eEBQSaFf03hvAsLH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(20558992708506)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(85664002)(24454002)(69234005)(189002)(16236675004)(3900700001)(33656002)(19617315012)(5002640100001)(54356999)(586003)(92566002)(19580405001)(7696003)(19580395003)(87936001)(101416001)(74316002)(9686002)(81166006)(66066001)(15395725005)(5001770100001)(50986999)(7736002)(6116002)(102836003)(11100500001)(97736004)(790700001)(3846002)(19300405004)(99936001)(106356001)(9326002)(8936002)(76576001)(7906003)(7846002)(189998001)(3280700002)(19625215002)(3660700001)(4326007)(8676002)(81156014)(105586002)(86362001)(2900100001)(2906002)(8666005)(77096005)(15975445007)(561944003)(122556002)(10400500002)(68736007)(2201001)(2501003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; 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/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0151_01D1F92D.149A8310" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2016 06:46:59.5984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0hTYRjHec85O5ur1evSfNA+1LAEIzMrmDi6UMIqJQlSs6COekpRp52t 64dYRRe1hUmKm1h2tSuTcmahhqsttRS1NLJsLs27oFmERZdt74Sgb7//8/8/L8/z8EpoeREb KEnX6HhBw2UqWCljTHy0ZdngDktC+Pszc5UVw41IaXOWi5R9765SSkfLmEhZpG9glJ2dNWKl fayHXSdWjzjaROpih4NVX78+Tal7ujso9dfXU6z6fIkZxbFJUlUqn5l+kBeWr9kjTSssLaRz zHbqcMWvWrEetV+h8pCPBPAqKOhtZ/KQVCLHZgSTzf2IiEYEZ1tfid2CwQYazA9GxcQppODu 6c8iIuwIXnysZ92PsVgFt63fPf1+2IjgkqnAI2isp+DGlzbanZqHE+GasdplSFypHVBpSSYY Bvd697qRwYvhqWGtG2U4CWrHfdx9CM+H7833PGPTOAC6+y97V/ADZ/tLlrA/DPf9FpF8Cnx5 ZxCR+kIYydd7M7HwzHTBMz7gcRaMXRaGGNEwNT6GCKdD+Quzt54BU/1PGNLQgODl1AhNjAXw 8GspIoaNBYPD6OmWYx4q7p9CZN1A6HmT6+UFMPShTkRuYkDQerJMXIBCTP+sZPrXcxsy7AtN xn7G5DoHjXdCUeUGkl8KBucpNMM3r4zShEOhpfOt+P96FJT8aGAJL4KL+U5vZjWM2iZROZp1 B/lreW1y1r6IiDBeSE/RarM1YRpe9wC5PmhD1c/wGjQ8uN6KsAQpZssW3qxKkIu4g9ojWVYU 7HrnU+XdNhTIaLI1vMJPtj/RkiCXpXJHjvJC9m7hQCavtaIgCaMIkG0dXpQgx/s4HZ/B8zm8 MONSEp9APdpp/3Oo/diGE9MrVVyjMzp281Vh7qbqrvjJo98yRs/WTKwQfAeyQpYY8zcdh41+ 26KpptiokbqhY/7bI+Wd9fUTqknL81v1q4MDWmuDNL6PbSVpOmvMrshYXdQP+8by+Ihiy7lc LpIzmudUR27tUMfTqgFpXPL4h59cSKmtLDhGwWjTuBWhtKDl/gLXovX3qAMAAA== Archived-At: Cc: Ingemar Johansson S , "Kevin.Smith@vodafone.com" , "tcpPrague@ietf.org" , "koen.de_schepper@nokia.com" , "tsvwg@ietf.org" Subject: Re: [tcpPrague] Impact of an L4S experiment on non-TCP transport using ECT(1) 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: Thu, 18 Aug 2016 06:47:09 -0000 ------=_NextPart_000_0151_01D1F92D.149A8310 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0152_01D1F92D.149A8310" ------=_NextPart_001_0152_01D1F92D.149A8310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =20 I have now given a fair enough time to get an answer to the question = whether or not there exist any implementations of 3GPP TS26.114 that = implements ECN support. The answer is still that I have not found any = evidence of such implementations.=20 Given this piece of information I don=E2=80=99t see a problem that = ECT(1) is redefined for L4S. =20 The proper way would of course be to write up an LS to 3GPP with a = reference to relevant L4S work and ask for feedback, I believe that this = possibility was brought up at the TSVWG session ? =20 /Ingemar =20 From: Ingemar Johansson S=20 Sent: den 20 juli 2016 22:51 To: 'csp@csperkins.org' ; 'ietf@bobbriscoe.net' = Cc: 'tcpPrague@ietf.org' ; Ingemar Johansson S = Subject: RE: [tcpPrague] Impact of an L4S experiment on non-TCP = transports using ECT(1) =20 Hi =20 FYI, I am trying to get some info if there are any implementations = (pending or existing) of ECN support for 3GPP MSTI according to = TS26.114. I am almost certain that there are no but it needs to be = checked out, given vacation period and all it may take a while to get a = clear answer. =20 /Ingeamr=20 =20 From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: den 20 juli 2016 10:34 To: Bob Briscoe > Cc: TCP Prague List > Subject: Re: [tcpPrague] Impact of an L4S experiment on non-TCP = transports using ECT(1) =20 Bob, =20 On 19 Jul 2016, at 19:22, Bob Briscoe > wrote: =20 Colin, For the writing about the proposed effect of L4S on RFC6679, see the L4S = problem statement section 1.4, item 3B) https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-proble= m-02#section-1.4 It there are any other RFCs beyond the list there that use ECT(1) that = we're not aware of, pls let me know. Can you explain the impact on circuit breaker? =20 The ongoing experiments with AQM and ECN, of which L4S is a part, have = made it very unclear how a transport should respond to ECN-CE marks, for = either ECT(0) or ECT(1). The circuit breaker got caught in that = discussion.=20 =20 Colin =20 =20 =20 =20 Prior to the problem statement, text about 6679 was written in the L4S = identifier draft that I've presented in tsvwg, and mentioned the effect = on other transports including RTP-ECN. We wrote what we thought the process would be in = https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#section-1.3= However, the tsv management have now clarified how they want this done = (I'm expecting discussion in tsvwg tomorrow now we've had the BoF). I can send you the draft text we're proposing to use to update 3168, = 6679 etc, if you want (or you can wait until it's actually submitted as = a draft, perhaps tonight. Essentially the idea is 2-stage: 1) a PS to obsolete RFC3540 (experimental) and to update RFC3168 RFC4960 = RFC6679 RFC4340 to reserve ECT(1) for future experiments again 2) the L4S identifier draft (draft-briscoe-tsvwg-ecn-l4s-id) to use the = newly reserved ECT(1) codepoint experimentally I appreciate that there might be implementations in progress that use = ECT(1), but as 6679 did not say what ECT(1) is for, I doubt it. If an RTP implementation is using a field in the IP header for something = that hasn't been standardised by the IETF and is not the current = experimental use (the ECN nonce), then I think it has no right to = complain if it gets stamped on by a new IETF-sanctioned experiment. You will recall I checked the intent of the ECT(1) text in 6679 on the = avtcore list some time ago. See your response then, pasted below. Bob -------- Forwarded Message --------=20 Subject:=20 Re: [AVTCORE] RFC6679 ECN in RTP: intent of ect =3D 0, 1, or random? Date:=20 Mon, 9 Nov 2015 10:55:14 +0000 From:=20 Colin Perkins To:=20 Bob Briscoe CC:=20 Ingemar Johansson S = , Magnus Westerlund = = , Ken Carlberg = =20 Bob, =20 This sounds interesting, and would be a good fit for the RMCAT working = group, but doesn=E2=80=99t sound like it would be an update to the = ECN-for-RTP RFC (which specifies ECN negotiation, marking, and feedback, = but no congestion control algorithms). =20 Colin =20 =20 =20 =20 > On 5 Nov 2015, at 10:04, Bob Briscoe = wrote: >=20 > Colin, >=20 > OK. In the fullness of time, if our proposal continues to get = traction, I'll draft a little experimental bis to ECN in RTP to specify = scalable congestion control. It will be v simple: >=20 > If using scalable cc: > * sender only uses scalable cc if (all) receiver(s) report ECN support > * sender rate equation is like TFRC equation, but with 1/p instead of = 1/sqrt(p) > * fall back to TFRC equation on loss rather than ECN (and also = possibly on ECN accompanied by high variable delay) for 'a few' 1RTT = (TBD) > * sender sets ECT(1) not ECT(0) > * no changes on receiver > * I think it would work deployed one RTP hop at a time, but that would = have to be tested >=20 > But I'd want to implement and test it first, of course. >=20 >=20 >=20 > Bob >=20 > On 05/11/15 07:34, Colin Perkins wrote: >> Bob, >>=20 >>> On 4 Nov 2015, at 17:50, Bob Briscoe = wrote: >>>=20 >>> Piers, >>>=20 >>> I realised I didn't send the mail thanking you for your response. = Thank you - v useful, and confirmation of my vague memory of events. >>>=20 >>> 1. Would the authors (and wider community) be happy to allow ECT(1) = not to be set-aside for future anti-cheating use, as long as there was = another way, in principle, for the sender to check for cheating? >> I have no objection. You might check with the RMCAT chairs, since = some of their proposals make use of ECN with RTP, but I doubt this will = be a problem. >>=20 >>> For TCP, we worked out a way for the sender to check for cheating = without burning a codepoint - by the sender introducing one or two CE = codepoints of its own, and checking the receiver reports them. Would = this be harder for RTP? Are the receiver reports deterministic enough = for the sender to determine whether codepoints it injected are correctly = counted in the next report? >> The sender could easily set a CE mark on a small number of packets = it=E2=80=99s sending. For unicast cases, where there=E2=80=99s an = explicit control loop, it should be able to correlate this with the = returned RTCP feedback. Where it might be difficult is with open loop = layered multicast congestion control, where some receivers might see the = CE mark and drop a layer since they don=E2=80=99t know it=E2=80=99s a = synthetic mark. >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >>> 2. A couple of days after I posted the original question, we posted = the -00 individual draft aiming to start the process of repurposing = ECT(1). You will see the sentence in the scope section = = >>>=20 >>> See security considerations for discussion on feedback integrity = checking. >>>=20 >>>=20 >>> Bob >>>=20 >>> On 19/10/15 10:15, Piers O'Hanlon wrote: >>>> Hi Bob, >>>>=20 >>>> I think the reasoning was that ECT(1)/random could potentially be = used to detect cheating/failures as mentioned in section 7.4, but I = can't see that it's going to make a lot of difference if ECT(1) is not = used. >>>>=20 >>>> Piers >>>>=20 >>>> On 17 Oct 2015, at 22:59, Bob Briscoe wrote: >>>>=20 >>>>> Guys, >>>>> [Ignore last identical email - I left the list off the distr in = error] >>>>>=20 >>>>> I'm writing a draft to propose a new use for ECT(1). >>>>>=20 >>>>> In reading RFC6679, It says that the there is no intent to use an = ECN nonce. >>>>> Also it says the receiver might want to advise the sender not to = use ect=3Drandom, if its behind a header compression link. And that = ect=3D0 is recommended and the default. >>>>>=20 >>>>> But it doesn't seem to actually say why a sender might send ECT(1) = instead of ECT(0). Or why a sender might use the two randomly. Or why a = receiver might ask for ect=3D1, or ect=3Drandom. >>>>>=20 >>>>> I'm trying to work out whether there would be any detriment to = RFC6679 if it couldn't use ECT(1). It looks like not. >>>>>=20 >>>>>=20 >>>>> Bob >>>>>=20 >>>>> --=20 >>>>> ________________________________________________________________ >>>>> Bob Briscoehttp://bobbriscoe.net/ >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>>=20 >>=20 >>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org =20 > https://www.ietf.org/mailman/listinfo/avt =20 =20 --=20 ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ =20 =20 --=20 Colin Perkins https://csperkins.org/ =20 =20 =20 ------=_NextPart_001_0152_01D1F92D.149A8310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi=

 

I have now = given a fair enough time to get an answer to the question whether or not = there exist any implementations of 3GPP TS26.114 that implements ECN = support. The answer is still that I have not found any evidence of such = implementations.

Given this = piece of information I don=E2=80=99t see a problem that ECT(1) is = redefined for L4S.

 

The proper = way would of course be to write up an LS to 3GPP with a reference to = relevant L4S work and ask for feedback, I believe that this possibility = was brought up at the TSVWG session ?

 

/Ingemar=

 

From:<= /b> = Ingemar Johansson S
Sent: den 20 juli 2016 = 22:51
To: 'csp@csperkins.org' <csp@csperkins.org>; = 'ietf@bobbriscoe.net' <ietf@bobbriscoe.net>
Cc: = 'tcpPrague@ietf.org' <tcpPrague@ietf.org>; Ingemar Johansson S = <ingemar.s.johansson@ericsson.com>
Subject: RE: = [tcpPrague] Impact of an L4S experiment on non-TCP transports using = ECT(1)

 

Hi=

 

FYI, I am = trying to get some info if there are any implementations (pending or = existing) of ECN support for 3GPP MSTI according to TS26.114. I am = almost certain that there are no but it needs to be checked out, given = vacation period and all it may take a while to get a clear = answer.

 

/Ingeamr =

 

From:<= /b> = Colin Perkins [mailto:csp@csperkins.org] =
Sent: den 20 juli 2016 10:34
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc:= TCP Prague List <tcpPrague@ietf.org>
Subje= ct: Re: [tcpPrague] Impact of an L4S experiment on non-TCP = transports using ECT(1)

 

Bob,

 

On 19 Jul 2016, at 19:22, Bob Briscoe <ietf@bobbriscoe.net> = wrote:

 

Colin,

For the writing about the proposed = effect of L4S on RFC6679, see the L4S problem statement section 1.4, = item 3B)
https://tools.ietf.org/html/draft-briscoe-tsvwg= -aqm-tcpm-rmcat-l4s-problem-02#section-1.4

It there are any = other RFCs beyond the list there that use ECT(1) that we're not aware = of, pls let me know.
Can you explain the impact on circuit = breaker?

 

The ongoing experiments with AQM and ECN, of which L4S = is a part, have made it very unclear how a transport should respond to = ECN-CE marks, for either ECT(0) or ECT(1). The circuit breaker got = caught in that discussion. 

 

Colin

 

 

 

 

Prior to the problem statement, text about 6679 was = written in the L4S identifier draft that I've presented in tsvwg, and = mentioned the effect on other transports including RTP-ECN.
We wrote = what we thought the process would be in https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#s= ection-1.3
However, the tsv management have now clarified how = they want this done (I'm expecting discussion in tsvwg tomorrow now = we've had the BoF).


I can send you the draft text we're = proposing to use to update 3168, 6679 etc, if you want (or you can wait = until it's actually submitted as a draft, perhaps = tonight.
Essentially the idea is 2-stage:
1) a PS to obsolete = RFC3540 (experimental) and to update RFC3168 RFC4960 RFC6679 RFC4340 to = reserve ECT(1) for future experiments again
2) the L4S identifier = draft (draft-briscoe-tsvwg-ecn-l4s-id) to use the newly reserved ECT(1) = codepoint experimentally

I appreciate that there might be = implementations in progress that use ECT(1), but as 6679 did not say = what ECT(1) is for, I doubt it.
If an RTP implementation is using a = field in the IP header for something that hasn't been standardised by = the IETF and is not the current experimental use (the ECN nonce), then I = think it has no right to complain if it gets stamped on by a new = IETF-sanctioned experiment.

You will recall I checked the intent = of the ECT(1) text in 6679 on the avtcore list some time ago.
See = your response then, pasted below.


Bob


-------- = Forwarded Message --------

Subject:

Re: [AVTCORE] = RFC6679 ECN in RTP: intent of ect =3D 0, 1, or = random?

Date:

Mon, 9 Nov 2015 = 10:55:14 +0000

From:

Colin Perkins <csp@csperkins.org>

To:

Bob Briscoe <ietf@bobbriscoe.net><= /o:p>

CC:

Ingemar Johansson = S <ingemar.s.johansson@= ericsson.com>, Magnus Westerlund <magnus.westerlund@eric= sson.com>, Ken Carlberg <carlberg@g11.org.uk><= /o:p>

 

Bob,<=
/pre>
 
This sounds interesting, and would =
be a good fit for the RMCAT working group, but doesn=E2=80=99t sound =
like it would be an update to the ECN-for-RTP RFC (which specifies ECN =
negotiation, marking, and feedback, but no congestion control =
algorithms).
 
Colin<=
/o:p>
 
 
<=
o:p> 
 
> On 5 Nov =
2015, at 10:04, Bob Briscoe <ietf@bobbriscoe.net> =
wrote:
> 
> =
Colin,
> 
> OK. In the =
fullness of time, if our proposal continues to get traction, I'll draft =
a little experimental bis to ECN in RTP to specify scalable congestion =
control. It will be v simple:
> =

> If using scalable =
cc:
> * sender only uses scalable cc if (all) =
receiver(s) report ECN support
> * sender rate =
equation is like TFRC equation, but with 1/p instead of =
1/sqrt(p)
> * fall back to TFRC equation on loss =
rather than ECN (and also possibly on ECN accompanied by high variable =
delay) for 'a few' 1RTT (TBD)
> * sender sets =
ECT(1) not ECT(0)
> * no changes on =
receiver
> * I think it would work deployed one =
RTP hop at a time, but that would have to be =
tested
> 
> But I'd want =
to implement and test it first, of course.
> =

> 
> =

> Bob
> =

> On 05/11/15 07:34, Colin Perkins =
wrote:
>> Bob,
>> =

>>> On 4 Nov 2015, at 17:50, Bob Briscoe =
<ietf@bobbriscoe.net> =
wrote:
>>> =

>>> =
Piers,
>>> =

>>> I realised I didn't send the mail =
thanking you for your response. Thank you - v useful, and confirmation =
of my vague memory of events.
>>> =

>>> 1. Would the authors (and wider =
community) be happy to allow ECT(1) not to be set-aside for future =
anti-cheating use, as long as there was another way, in principle, for =
the sender to check for cheating?
>> I have =
no objection. You might check with the RMCAT chairs, since some of their =
proposals make use of ECN with RTP, but I doubt this will be a =
problem.
>> =

>>> For TCP, we worked out a way for the =
sender to check for cheating without burning a codepoint - by the sender =
introducing one or two CE codepoints of its own, and checking the =
receiver reports them. Would this be harder for RTP? Are the receiver =
reports deterministic enough for the sender to determine whether =
codepoints it injected are correctly counted in the next =
report?
>> The sender could easily set a CE =
mark on a small number of packets it=E2=80=99s sending. For unicast =
cases, where there=E2=80=99s an explicit control loop, it should be able =
to correlate this with the returned RTCP feedback. Where it might be =
difficult is with open loop layered multicast congestion control, where =
some receivers might see the CE mark and drop a layer since they =
don=E2=80=99t know it=E2=80=99s a synthetic =
mark.
>> 
>> =
Colin
>> 
>> =

>> 
>> =

>>> 2. A couple of days after I posted =
the original question, we posted the -00 individual draft aiming to =
start the process of repurposing ECT(1). You will see the sentence in =
the scope section <https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-=
00#section-1.3>
>>> =

>>> See security considerations for =
discussion on feedback integrity =
checking.
>>> =

>>> 
>>> =
Bob
>>> 
>>> =
On 19/10/15 10:15, Piers O'Hanlon =
wrote:
>>>> Hi =
Bob,
>>>> =

>>>> I think the reasoning was that =
ECT(1)/random could potentially be used to detect cheating/failures as =
mentioned in section 7.4, but I can't see that it's going to make a lot =
of difference if ECT(1) is not =
used.
>>>> =

>>>> =
Piers
>>>> =

>>>> On 17 Oct 2015, at 22:59, Bob =
Briscoe wrote:
>>>> =

>>>>> =
Guys,
>>>>> [Ignore last identical =
email - I left the list off the distr in =
error]
>>>>> =

>>>>> I'm writing a draft to =
propose a new use for ECT(1).
>>>>> =

>>>>> In reading RFC6679, It says =
that the there is no intent to use an ECN =
nonce.
>>>>> Also it says the =
receiver might want to advise the sender not to use ect=3Drandom, if its =
behind a header compression link. And that ect=3D0 is recommended and =
the default.
>>>>> =

>>>>> But it doesn't seem to =
actually say why a sender might send ECT(1) instead of ECT(0). Or why a =
sender might use the two randomly. Or why a receiver might ask for =
ect=3D1, or ect=3Drandom.
>>>>> =

>>>>> I'm trying to work out =
whether there would be any detriment to RFC6679 if it couldn't use =
ECT(1). It looks like not.
>>>>> =

>>>>> =

>>>>> =
Bob
>>>>> =

>>>>> -- =

>>>>> =
________________________________________________________________
>>>>> Bob Briscoehttp://bobbriscoe.net/<=
o:p>
>>> -- 
>>> =
________________________________________________________________
>>> Bob Briscoehttp://bobbriscoe.net/<=
o:p>
>>> 
>> =

>> 
> =

> -- 
> =
________________________________________________________________
> Bob =
Briscoe           =
            &=
nbsp;       http://bobbriscoe.net/
> 
> =
_______________________________________________
>=
 Audio/Video Transport Core Maintenance
> avt@ietf.org
> =
https://www.ietf.org/m=
ailman/listinfo/avt
 
 
-- =

___________________________________________________=
_____________
Bob =
Briscoe           =
            &=
nbsp;       http://bobbriscoe.net/

 

 

-- 

Colin = Perkins

 

 

 

------=_NextPart_001_0152_01D1F92D.149A8310-- ------=_NextPart_000_0151_01D1F92D.149A8310 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVYzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGADCCA+igAwIBAgIQ eyeE6FBBHSc8YzDpWR1mVTANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDIxNDI5MTdaFw0xNzEy MDIxNDI5MTZaMHQxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3Nv biBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTEQMA4G A1UEBRMHRVBMSUpPSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6dOkJu7hl4aOKX k6YBf5PgWpDbO6iINxyYJetBuJZJqEdDqKukaHZmP8Rn5hhiQZDWa89koR41DNS7umMwZtHQkN+j m3b5Z1LUMQle7XDtUy3rn47hgjYUFgZOEp1fWYIoAKxZNOTf4AfiMbOGn2t8IFxe8JUYrAVy6tAE YnSnPM+nn4UeipLBwncBVhxUQU5R4W8b5k7tY8HJB+CWGgSbkyLWfxeuiwAA48nKqa6fOqo2ZpS4 ukNf9u8Hk3fIT8XvDJVnT2NwB7Z29oL3Fq20tm4M96SkuLlNjLZ9wvskfmYAk+PUP44ugvkB7Uon cAzoPXlkz3N5IB9Ly7/SIgsCAwEAAaOCAcYwggHCMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVh bGNhdjIuY2VyMCsGA1UdEQQkMCKBIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQUOrfg77a5Xcj2OffxTY1aeC+5CqEwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9v BsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQCddA412wylfbLwBiyQ uVz1IDcaYZ14Yh1L52IhX14BGl0eNc/5BbWL3yCF2eGv8h6FmckZHOM7+OS4g+inNZbaKysTkLah T3UbrUWFPpkZFAS1HfaxBJZTVS3UIVnIYP06ZvRRRNf3VJzwpZSES4tu0euzI2CatWCZLa+N4QyT ZkMnw1JLUXbz0dPA40b9Qdoec23PkpMqf1CxNNuaRBF9L5wKGily7RyPOtkcrWJ3R2oSGC7ugKK9 vWzQzEHoE95txgF/kq7MdRJks8BXqnb3w8Fthu+1zIORjcR9yxv1e9gYo0ZcaPqyjC/LDdzsHv59 5hkwQnxAGyPDBgCdq5Ion/4Lx+YI61SKcyGEH+VYD6CJX44/IfRAE+tq8BHZYOJLW8uCd7Jboqd2 jklsUfSPN8i4cvQpfYzDkrSziyfcvdplEvxSEbTEFZ+w6IbvCtV0xBSfS9+RhqBOn6LZSdw/jp+b 9penQAWekRykrKyKroDtwesqg0HbC7bkprqOwSaar5gcFGYVYJ5JuHT3Ou44hGn/yiwbTnc2Mb12 8nWesZQZvIT2n5Y42ZYebo1cLBYdF6U/Q5OHLOUk596LephQggvKphe7F2w87CpaUUoANa4H1ri+ LTOKdz+itrkbu3dDs6oDZuSwMU3fJaf8d/3PPLoGJtFQWQ8v2e/Oxxe0sDCCBrYwggSeoAMCAQIC EQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJh MR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUy NzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqj ddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZ abrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtV aqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldV JtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJ iOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgv jVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvc IzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQw gYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3Qu dGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZx f0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBu ByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9Iewy aV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy0 4/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEu eSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWX I0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5l JPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Y u0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGC AvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODE4MDY0NjU4WjAjBgkqhkiG9w0B CQQxFgQUmc3hgaRO3S79ilqRGjP1szNfCC8wWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQeyeE6FBBHSc8YzDpWR1mVTBfBgsqhkiG9w0BCRAC CzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwDQYJKoZIhvcNAQEBBQAEggEAEfsrhzehAqTXPbZc ARBZFNLH+wfa71sj3NkvR8zjM6IaBvoJGLnHcXCP8vCa3Oc8R7epom8+an6udzLGiPPQh906owNV NNDJDNwmIwKg5FyVRAnMxnGvanLIEYc25qbXw3vsMUpbLElP1hZ2n1Q6SRJQd6eNXmaBR+s39dIM oksMoNg5P5ag4xgMgpU2v+FzN5ynXf6p4aHTb0sKsmZNq9jUtdXePI5E9TwRNk2EZEyVgn8gWh0w QUDbuAkR/U/E+RFnSIoIEmZ1IPWU0CioatTp1+Q7bmiYG5uHEGIH5spYyNAZUXCew23vKO+hYB0I NNFh4iLCetYDCCYCNfGmFQAAAAAAAA== ------=_NextPart_000_0151_01D1F92D.149A8310-- From nobody Thu Aug 18 01:05:55 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 1F4BC12D0CA for ; Thu, 18 Aug 2016 01:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 L6936so7vfNt for ; Thu, 18 Aug 2016 01:05:49 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C84A12D0B5 for ; Thu, 18 Aug 2016 01:05:47 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id n128so11650605ith.1 for ; Thu, 18 Aug 2016 01:05:47 -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; bh=y6LJiuW44bFkTnJCT9ljMTLoVk22Vqf22OsO5lA1H0s=; b=ufKhuypXfDIsU8z+U70prs+7GkdrnsOlxcZRL0wVYN86SHJ2qVZUKMvn5k2g5q6EWx KvO/+HKxMZz2L6zDrMONy11STbjS+9zD1rLW+LxhoUcCq/oTCj8KmXCNWp2+fG0y3SvK K2RVny1VHGMvFIc2ks8q0qpqPeUSUEL/mKEV4= 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; bh=y6LJiuW44bFkTnJCT9ljMTLoVk22Vqf22OsO5lA1H0s=; b=cEXqD5PeQtCDcznp5tsSF2x0TaUrFJ82JVZvk5Zr7YuMXePXB5CQeawZzSWW+9V6yy z+fnrrq36NU7KOH6IS/1C1CJk73+mYZxK2mvrgNTwhDXj0K6AK4WnWzvaUNtU2Xd6Hvb PrIPXJy86RdM2NQZT7b74CbxcmFspzTm78f0YZN812T7XQJW0rk5M1rnOWjVE9WDavca jje3GRQLyFnyKDQtDKaa71DgPml+peh/FOVT2R7wlaBLljVpADJByxUhQ/VQycIKtCJz ON5DrUFwpBkGM3uso3SXQYsK2xLrVH0l5z79N2C6pkeyOcTOpeXcPkiQzjZ0PPleowPD 5mIQ== X-Gm-Message-State: AEkoouvoxKl2J3kzcXyr45k3C4VS3e0b7w0/OJYDRwU5DzR5lOqUmPgUILkBZ1sqIt4nE8sjOa2V5ldadta4FP+D/tT9MMvjcZaKx/laqV7q9OY5B4jceuIKuLnDD0jfLE0VWuUHnNeNeQ== X-Received: by 10.36.210.68 with SMTP id z65mr1760438itf.32.1471507547133; Thu, 18 Aug 2016 01:05:47 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> <623f46dedcc661ae74563f6bf08f46a5@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGd4OoGFyImcsqDlVk0oY8T3VfV3QH845XxAem+5TgCNV3HJwFbXVb9ANTgh9KgdCWb0A== Date: Thu, 18 Aug 2016 10:05:45 +0200 Message-ID: <00594c32f56877bfc2fde20132250174@mail.gmail.com> To: Yuchung Cheng Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: marcelo bagnulo braun , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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: Thu, 18 Aug 2016 08:05:52 -0000 HI Yuchung, Marcello > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: 15. august 2016 18:49 > To: Karen Elisabeth Egede Nielsen > Cc: marcelo bagnulo braun ; TCP Prague List > ; tcpm IETF list > Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt > > On Mon, Aug 15, 2016 at 2:00 AM, Karen Elisabeth Egede Nielsen > wrote: > > Hi Yuchung, > > > >> > > >> > An additional comment is that new approaches to retransmissions - > >> > like TCP TLP and TCP RACK (also SCTP TLR which however is not > >> > progressing at the moment) might fundamentally alter the picture. > >> > I.e., if retransmissions are sent pro-actively in tail loss > >> > situations then more conservative RTOs may be kept for situations > >> > where it is prudent to wait longer. Don't know if TCP TLP is so > >> > widely deployed that it is something that you should relate to even > >> > if it may be superseded by RACK. Just a thought. > >> TLP and RACK help reduce timeout cases in DC environment for sure. > >> But still it can not completely avoid timeouts. > > > > [Karen Elisabeth Egede Nielsen] Agreed. > > > > For SCTP TLR we still see RTO-timeouts when also > > probes/retransmissions are lost. > > I assume that it would be something like this also for Rack/TLP - > > though potentially depending on how many consecutive probes that are > allowed. > > The role of RTO-timeouts are different when RACK/TLP is enabled and it > > might be counterproductive to have RTO-timeouts be too aggressive as > > the function indeed with TLP/RACK becomes something much closer to the > > original intend > > (read: how I understand the original intend) - namely to introduce a > > pause for the network to recover when things are really (consistently) > > bad. > > > > If the RTO is lowered down to be comparable in order of magnitude with > > the RTT (with some delay_ack considerations) we are narrowing the > > situation where TLP/RACK probing is able to kick in before > > RTO-retransmissions starts anyway. > > > > I understand that RTOs should be adjusted to the network dynamics, but > > I do think that it is important to understand - for the DC environment > > - if the need for the low RTOs in DC's is motivated mainly by having > > RTO-retransmissions fix the tail loss recovery deficiencies of TCP, > > which RACK/TLP addresses, or more generally for a need for more timely > > probe and reactivation for/after network recovery. > > > > Or perhaps you see the TLP probe timeout and the RTO timeout > > eventually being driven by the same timer, the reactions (e.g. CC > > reactions) then possibly depending on state (probe already sent or > > not). > I agree with your thought here. > > More generally, I'd like to evolve the state of art recovery with these > principles: > 1. React with ack events as much as possible > > 2. Send tiny probes to trigger (1) after 2-3 RTTs > > 3. Have conservative RTOs that (exp-backoff) expire at an order of RTT to > repair the head for reliability. > > > On thing about RTO: RTO current reset cwnd to 1 upon firing no matter > what. > We should ONLY reset cwnd to 1 if no news (acks/data) for a long duration. > This is quite important for performance: today cwnd is reset to 1 even if > every packet but the first one has been recently delivered. This > unnecessarily conservative because the ack clock isn't lost yet. But the > collateral damage to performance is huge on large BDP networks. This > results > work-arounds to shorten and avoid RTOs. > > > I'd like to address these points in the upcoming RACK/TLP draft. > > [Karen Elisabeth Egede Nielsen] I agree completely with your view and approach. In respect to the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the given recommendations for low RTO is that they do not (likely) take 2. Into account - meaning that they are looking for the low RTO to solve 2 for tail recovery. The bad thing is that they then also get the CWND reductions (as you also say). I would like for that this aspect is taken into consideration/given thoughts in the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the general 4LS effort. If we end with very low recommendations for RTO in order to handle 2. we risk undermining the RTO-retransmission function as well as the TLP function for now and forever. It might be that one for TCPs, that do not support TLP(/RACK), need to operate with very low RTOs to handle tail loss's "fast enough", but the recommendation for "future standard ?" TCP with TLP always enabled might be different. In this context lowering the RTO to handle 2. should be considered as a "temporary hack" ? BR, Karen From nobody Fri Aug 19 10:11:11 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 28AED12D623 for ; Fri, 19 Aug 2016 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 u9_JshFmdtbR for ; Fri, 19 Aug 2016 10:11:08 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE4712D5F0 for ; Fri, 19 Aug 2016 10:11:08 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id f6so6183274ith.0 for ; Fri, 19 Aug 2016 10:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HKK//jZo6Ukf7wuP/TqqjvIZfroiM5nrv+pBHcghv6M=; b=QyblFUFDfD+j48CJwp9jbWdfJr99DEYlq4EtJNsEMXI23QfZP6olOWZqcj/wv8RH7v bH9MRLtTQk5xvZNx09IB2eKJqWDamMLETtS3OLfTES+oZ4+fmVg+oK9SStbDzA13jX88 n3vt1lvQ7/UAL3WVXe2F65wCtY8rYQJkgPlugNgROTlqrKc+k83afolB3azR4Y3fIeOF 89Cs9XSE0yJv5bnRx+odLZLufzPM19KtAgj/R/DW/EpVZI14YKdzLHbXHj873gi3gR8S CXwiXdFWB8nJUNKqOf5jTg4bs7R7Cxhh0MtpSf3eQIWkSHROkhrtGEmLKXiSFVmfxFem D0ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HKK//jZo6Ukf7wuP/TqqjvIZfroiM5nrv+pBHcghv6M=; b=J2yn2kxdy8kC/T3W2PNpSvLTpMW/XVSkhrdSLtzh481Mj/Z9+/wiKXd9zrBF/F6J6N ZOx+qi4Il/CloeQW6mju6wmXaOgPJ7H0AckYIZhVz3YfChXXeAfxAcS/11uqUIS9sT57 DMZj85XMQ3lgGZQG1Cm4ElyDbtqJcbypN0FUiYFvwZwCvK/WmsZGV/7gl1/T2S8XvxKU 16zjYnaQNx/j53gr0FfEqLupMQwKmosQJdGH04goeSFq3ylwYY7qE4+ampFfOvtLzOCz 7/j5BLD3wlIrIgrYiX0222RTSAsScQmodplagJCTYex5rjiQX1+uvrMdA6UB/gtkUP7d 9G4w== X-Gm-Message-State: AEkoousvb6L9fq4v2qrI4+ZUUubH4JLIjhAzdeovDZLApXxQH4+Y68NibPLUuSPKPBQJ9E3+YCUebaDc4V+Q/KxW X-Received: by 10.36.82.81 with SMTP id d78mr7394747itb.65.1471626667205; Fri, 19 Aug 2016 10:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.244.103 with HTTP; Fri, 19 Aug 2016 10:10:26 -0700 (PDT) In-Reply-To: <00594c32f56877bfc2fde20132250174@mail.gmail.com> References: <20160708211635.32095.77047.idtracker@ietfa.amsl.com> <2f56d1b8-7450-42de-4a24-53df9cf4c045@it.uc3m.es> <623f46dedcc661ae74563f6bf08f46a5@mail.gmail.com> <00594c32f56877bfc2fde20132250174@mail.gmail.com> From: Yuchung Cheng Date: Fri, 19 Aug 2016 10:10:26 -0700 Message-ID: To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: marcelo bagnulo braun , tcpm IETF list , TCP Prague List Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-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, 19 Aug 2016 17:11:10 -0000 On Thu, Aug 18, 2016 at 1:05 AM, Karen Elisabeth Egede Nielsen wrote: > [Karen Elisabeth Egede Nielsen] I agree completely with your view and > approach. > > In respect to the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the given > recommendations for low RTO > is that they do not (likely) take 2. Into account - meaning that they are > looking for the low RTO to solve 2 for tail recovery. > The bad thing is that they then also get the CWND reductions (as you also > say). > > > I would like for that this aspect is taken into consideration/given thoughts > in the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the general 4LS > effort. > If we end with very low recommendations for RTO in order to handle 2. we > risk undermining the RTO-retransmission function as well as the TLP function > for now and forever. > > It might be that one for TCPs, that do not support TLP(/RACK), need to > operate with very low RTOs to handle tail loss's "fast enough", but the > recommendation for > "future standard ?" TCP with TLP always enabled might be different. In this > context lowering the RTO to handle 2. should be considered as a "temporary > hack" ? One feature worth discussion in the draft is the penalty of cwnd=1 on spurious timeouts. For DC, the RTT is so fairly low that we may consider a false reset of cwnd to 1 is not a big deal. But consider in world of 100Gbps BDP will still be hundreds of packets so it is going to be a non-trivial penalty. Therefore it is important to discuss the timeouts with the remedy operations: how well can the connection detect spurious timeouts: F-RTO or Eifel are the two algorithms by IETF, Linux also supports DSACK-based undo. However, both F-RTO and Eifel have their limitations: F-RTO requires the sender to have new data to transmit after the first DUPACK of timeout. In the DC world, the requests or responses are often short enough to prevent that. Eifel relies on timestamps which is ticked at an interval higher than the DC RTT (e.g., Linux == jiffies == 1ms often), therefore the timestamps fail to distinguish original and retransmit if RTO was fired before the next tick. I plan to cover these aspects in next RACK rev. > > BR, Karen