From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 132FB3B29D; Mon, 2 Dec 2019 02:19:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575271142; bh=OiINsAjLL8q3mgM03EUdgEYnrEONnUoYpim88MYTYaA=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=GKbs7owo8IZ+GuojZ45x0JnIY+s4mWj3vDg9yIgqTCABAW9eXE3qGtwfWAFDx4j1z spxrQwlSvzILen8iitG+jDtccp/vrFcYR5t+g/XVsOlDJXYj0dGxuYiF7Gv5QN9au1 LEFPZdaCNY6zb9IMeW2KVNditYFO7jo4muMKedHo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.27.215.49] ([80.187.109.185]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8XU1-1hgdPj2i9Z-014VcL; Mon, 02 Dec 2019 08:19:02 +0100 Date: Mon, 02 Dec 2019 08:18:48 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <87tv6jl3c4.fsf@taht.net> References: <201912011730.xB1HUERp026709@gndrsh.dnsmgr.net> <87tv6jl3c4.fsf@taht.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Dave Taht CC: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, Jonathan Morton , ECN-Sane , bloat From: Sebastian Moeller Message-ID: <7D149065-2814-4E8F-A0BB-19CBA218534F@gmx.de> X-Provags-ID: V03:K1:P7dVxkDWvpW6TcXZpsxoLqbwDRkwrkuTWMgOUzVJtiLIVM7dwRI sLnOYabNHRSMIJ+cQNJwmqS1UWqVgOI9LbtCkeatWyRBY1hlxVVZtHh1BosJyz41PHzzHJr MPsw+Cp5vOzdYLPKlb+ubwm+4e7fDp+u6o9CxzrULClKAdUcFA+ZkfbX5eUaEOYkdmIGl+A PYj+SzOrALhRgwzQMQcRg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:sWH6q0Y1tvU=:WSqQEoxMt1/uroQrM29cd3 fViBtglWUIxJgC6ndBmisIb10cCCGHZJn1nAXUd1OO4+DRiWH8CfhYkXeq4BFGtM4KmsqNafD vGNRATkw9zghyTResYlVlc66sFJal2/ctYx+mzVpcJagQvpzPjXMb9Z4Wi+pbZzb6gM7Gif8F QRV22Hca6Ncex0cjmWUgw7XQW/9pvrdD6LvGFxSLiIK5KpvrgqTNpqil8+rLxYH8CLT979d4D QPtPvWCpYyECGAPqh2NjH6+A0dgwFg6wwBZ98xRTCkZnGfNcVcyqCsKxlSEFZ+mnN/DVFMk7u HGTiY8FIrsOCOBURY/4FEhuFcRjLbxF0FfSnlTLS4Y3nZy0R5DsmpmqvpuciVGEfK8k4y71hW sifPPNVGNE91HiMqT/E5fpxYE+ETIB6gNPRv9SM3MbxUHkwQ+SArp81f+tErQvbgT0bzw41Jl JtuH9ShpYsIwabeFZ90sCgUMxAOKfG3YY6OJGF8EE+rmWwRRax1lycVNmNZpdCALXq+S1LPxh K0jfmtGzmLZtj4iKihV/0PcBQFm+vq+msDJC5Mf7yCWBe1amrr6JwT3Ry0uwz5O8o4eRNh6RY RkWSgd4ZvJ7/64lmzXZdj+N6OCUmwYZuV4orgJmLXjU57UJfPQqcCdNfI/Rrijm9QLq5wqcNP CcXYNNgDwhgFLhUmaqXzpuw6BtcoR4OuqKAudOmiax7d2r55Hml1oADidKHLjwHO1iAFA7wcJ awsNu826KiTbbc47XfyUiH1cPQmrQ/sN8vTjXjVoysWtl/t3hKBFzZXTDTKiydx2RA8iJMmPW 9mCUDWlj5Ycu/4MJ/QSIErmh9kB3i2W0Il+YPXfmwfjQXf9T97sLQJQ6dbpqIZiQ02dR/mK4f sFFVVEbQgJPpJEL2OxuZpZEDErowlF47Tsf5gMxDDc46DZ6JiUxiMl0xnjXbkqd+eyftSaxy5 I+fzOH8sP45Snq0SsbPa0CTjIjZRgrIVdo8lQO/VsOMsdLEtsfepRt2i4MfRbHnZ27Dmqgvca ovOh1/Pmk/x4BkOr7RxspLkSACzjNCzZq7FrUjaVpgGrzJtZ+vhN++kgxE4fDSLgMkauOFAhp LdvkoXavSSBWL0w1ANWzsUo6AdwqY269FsaZB2Xy/dbQPCECZ/bN1ikgCfAhnllq1f9xup3xT AMZftjGaDn03y02OgcVIh43d327fkmpnnAfqoSj3Hq9WZGL7vyVfjO9rC2BLvcKGkDTQJSTnQ KUgzN+DWy4WtOgNJIyLuFM/iNFpKRXS5CnLkSCCJyhhrvJuI/Scb66eCPyiw= Subject: Re: [Ecn-sane] [Bloat] sce materials from ietf X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 07:19:05 -0000 Hi Dave, On December 2, 2019 6:10:51 AM GMT+01:00, Dave Taht wrot= e: >Sebastian Moeller writes: > >> Hi Rodney, >> >> >>> On Dec 1, 2019, at 18:30, Rodney W=2E Grimes <4bone@gndrsh=2Ednsmgr=2E= net> >wrote: >>>=20 >>>> Hi Jonathan, >>>>=20 >>>>=20 >>>>> On Nov 30, 2019, at 23:23, Jonathan Morton >wrote: >>>>>=20 >>>>>> On 1 Dec, 2019, at 12:17 am, Carsten Bormann >wrote: >>>>>>=20 >>>>>>> There are unfortunate problems with introducing new TCP options, >>>>>>> in that some overzealous firewalls block traffic which uses >>>>>>> them=2E This would be a deployment hazard for SCE, which merely >>>>>>> using a spare header flag avoids=2E So instead we are still >>>>>>> planning to use the spare bit - which happens to be one that >>>>>>> AccECN also uses, but AccECN negotiates in such a way that SCE >>>>>>> can safely use it even with an AccECN capable partner=2E >>>>>>=20 >>>>>> This got me curious: Do you have any evidence that firewalls are >friendlier to new flags than to new options? >>>>>=20 >>>>> Mirja Kuhlewind said as much during the TCPM session we attended, >>>>> and she ought to know=2E There appear to have been several studies >>>>> performed on this subject; reserved TCP flags tend to get ignored >>>>> pretty well, but unknown TCP options tend to get either stripped >>>>> or blocked=2E >>>>>=20 >>>>> This influenced the design of AccECN as well; in an early version >>>>> it would have used only a TCP option and left the TCP flags alone=2E >>>>> When it was found that firewalls would often interfere with this, >>>>> the three-bit field in the TCP flags area was cooked up=2E >>>>=20 >>>>=20 >>>> Belt and suspenders, eh? But realistically, the idea of using >>>> an accumulating SCE counter to allow for a lossy reverse ACK path >>>> seems sort of okay (after all TCP relies on the same, so there >>>> would be a nice symmetry )=2E >>>> I really wonder whether SCE could not, in addition to its current >>>> bit, borrow the URG pointer field in cases when it is not used, or >>>> not fully used (if the MSS is smaller than 64K there might be a few >>>> bits leftover, with an MTU < 2000 I would expect that ~5 bits might >>>> still be usable in that rate case)=2E I might be completely of to >>>> lunch here, but boy a nice rarely used contiguous 16bit field in >>>> the TCP header, what kind of mischief one could arrange with that >>>> ;) Looking at the AccECN draft, I see that my idea is not terribly >>>> original=2E=2E=2E But, hey for SCE having an additional higher fideli= ty >>>> SCE counter might be a nice addition, assuming URG(0), urgent >>>> pointer > 0 will not bleached/rejected by uninitiated TCP >>>> stacks/middleboxes=2E=2E=2E >>>=20 >>> We need to fix the ACK issues rather than continue to work around >>> it=2E Ack thinning is good, as long as it does not cause information >>> loss=2E There is no draft/RFC on this, one needs to be written that >>> explains you can not just ignore all the bits, you have to preserve >>> the reserve bits, so you can only thin if they are the same=2E >>> Jonathan already fixed Cake (I think that is the one that has ACK >>> thinning) to not collapse ACK's that have different bit 7 values=2E >> >> Well, I detest ACK thinning and believe that the network >> should not try to second guess the users traffic (dropping/marking on >> reaching capacity is acceptable, but the kind of silent ACK thinning >> some DOCSIS ISPs perform seems actively user-hostile)=2E But thinning >or >> no thinning, the accumulative signaling is how the ACK stream deals >> with (reasonably) lossy paths, and I think any additional signaling >> via pure ACK packets should simply be tolerant to unexpected losses=2E >I >> fully agree that if ACK thinning is performed it really should be >> careful to not loose information when doing its job, but SCE >hopefully >> can deal with whatever is out in the field today (I am looking at you >> DOCSIS uplinks=2E=2E=2E), no? > >I happen to not be huge on ack thinning either, but the effect >on highly assymetric networks was pretty convincing, and having >to handle less acks at the sender a potential goodness also=2E > >http://blog=2Ecerowrt=2Eorg/post/ack_filtering/ > >At the time we did I thought it could be made even better, >if we allowed more droppable packets to accumulate on each >round, it would both be "fairer" and be able to "drop more" >over each round=2E > >https://github=2Ecom/dtaht/sch_cake/issues/104 > >Never got around to it=2E > >I'd much rather have fewer highly assymmetric networks,=20 +1, I will not hold my breath though on getting this anytime soon= =2E=2E=2E GPON by default is asymmetric (2:1) and full duplex DOCSIS requir= es costly plant changes and got moved from the 3=2E1 spec to 4, and the DSL= s simply have no symmetric Bandplans I know of (well G=2Efast has, but that= only helps if the G=2Efast uplink is not running over GPON)=2E But then GP= ON's 2:1 ratio would already be most of the way to symmetry=2E=2E=2E and the >endpoint tcps do the thinning (which is what more or less happens >with GSO), but=2E=2E=2E=2E Yepp, the endpoints basically show be in control of the ACK rate,= but also should be considerate=2E > >secondly, I note that "ack prioritization" is a very common thing in >multiple shapers I've looked at, starting with wondershaper and in many >others (including dd-wrt)=2E A lot of these are *wrong*, wondershaper, >for >example, only recognized 64 byte acks=2E I think more than a few modems >do ack prioritization rather than "thinning"=2E I believe indiscriminate ACK boosting to be the wrong thing for a= tiered prioritization scheme, as ACKs should have the same priority as the= rest of the flow=2E But for the fidelity of the feedback loop, less delay = for ACKs seems benign, no? > >thirdly, protocols such as QUIC are already sending less >acknowlegements per packet than most TCP do, which is a a good thing=2E Again, +1, the endpoints should know best=2E > >fourthly, I've been meaning to try thinning on wifi for a while=2E Wifi >has a problem in that only a fixed number of packets can fit >in a txop and everything in a txop is usually sent reliably=2E=20 > >Here's 5 days worth of data from one of my sites=2E It's not hugely >loaded in the uplink direction, but roughly 11% of all packets are >dropped=2E=20 Almost all of those were ACKs though, I guess I see why you consid= er it unwise to hoist these over the wifi link only to filter them at your = edge router=2E=2E=2E=2E Best Regards Sebastian > > >qdisc cake 8007: dev eth0 root refcnt 9 bandwidth 9Mbit diffserv3 >triple-isolate nat nowash ack-filter split-gso rtt 100=2E0ms noatm >overhead 18 mpu 64=20 >Sent 13088217784 bytes 96513781 pkt (dropped 12173093, overlimits >155529797 requeues 558)=20 > backlog 0b 0p requeues 558 > memory used: 1144944b of 4Mb > capacity estimate: 9Mbit > min/max network layer size: 28 / 1500 > min/max overhead-adjusted size: 64 / 1518 > average network hdr offset: 14 > > Bulk Best Effort Voice > thresh 562496bit 9Mbit 2250Kbit > target 32=2E3ms 5=2E0ms 8=2E1ms > interval 127=2E3ms 100=2E0ms 103=2E1ms > pk_delay 4=2E7ms 2=2E0ms 709us > av_delay 1=2E3ms 162us 69us > sp_delay 50us 3us 3us > backlog 0b 0b 0b > pkts 150501 108280345 256028 > bytes 146280265 13846693704 40682021 > way_inds 181 7552458 26288 > way_miss 6579 1383844 20861 > way_cols 0 0 0 > drops 125 2682 0 > marks 171 277 0 > ack_drop 0 12170286 0 > sp_flows 2 5 0 > bk_flows 0 2 0 > un_flows 0 0 0 > max_len 4542 28766 2988 > quantum 300 300 300 > >> >>>=20 >>> Note that I consider the time of the arriving ACKS to also be >>> informaition, RACK for instance uses that, so in the case of RACK >>> any thinning could be considered bad=2E >> >> I am with you here, if the end-points decided to exchange >> packets the network should do its best to deliver these=2E That is >> orthogonal to the question whether a every-two-MSS packets ACK rate >is >> ideal for all/most applications=2E >> >>> BUTT I'll settle for not tossing reserved bit changes away as a >>> "good enough" step forward that should be simple to implement (2 >>> gate delay xor/or function)=2E >> >> Fair enough, question is more, what behavior happens out in >> the field, and could any other bit be toggled ACK by ACK to reduce >the >> likelihood of an ACK filte to trigger? >> >> Best Regards >> Sebastian >> >> >>>=20 >>>> Sebastian >>>>> - Jonathan Morton >>> --=20 >>> Rod Grimes =20 >rgrimes@freebsd=2Eorg >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/bloat --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E