From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6602521F35F for ; Thu, 23 Apr 2015 06:17:25 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 90E45DE4002; Thu, 23 Apr 2015 15:17:24 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 89522DE4001; Thu, 23 Apr 2015 15:17:24 +0200 (CEST) Received: from [10.193.116.35] (10.193.116.35) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Thu, 23 Apr 2015 15:17:23 +0200 Message-ID: <5538F0E0.7030308@orange.com> Date: Thu, 23 Apr 2015 15:17:20 +0200 From: MUSCARIELLO Luca IMT/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Dumazet References: <20150422040453.GB36239@sesse.net> , <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> , <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <5537DE4D.8090100@orange.com> <553882D7.4020301@orange.com> <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: MUSCARIELLO Luca IMT/OLN List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 13:17:54 -0000 On 04/23/2015 08:48 AM, Eric Dumazet wrote: > Wait, this is a 15 years old experiment using Reno and a single test > bed, using ns simulator. from that paper to nowadays several other studies have been made and confirmed those first results. I did not check all the literature though. > > Naive TCP pacing implementations were tried, and probably failed. Except for the scaling levels that sch_fq is pushing to nowadays growth, the concept was well analyzed in the past. > > Pacing individual packet is quite bad, this is the first lesson one > learns when implementing TCP pacing, especially if you try to drive a > 40Gbps NIC. this is the main difference I think between 2000 and 2015 and main source of misunderstanding. > > https://lwn.net/Articles/564978/ is there any other documentation other than this article? > > Also note we use usec based rtt samples, and nanosec high resolution > timers in fq. I suspect the ns simulator experiment had sync issues > because of using low resolution timers or simulation artifact, without > any jitter source. I suspect that the main difference was that all packets were paced. The rates of the first experiments were made at a very low rate compared to now so the resolution was not supposed to be a problem. > Billions of flows are now 'paced', but keep in mind most packets are not > paced. We do not pace in slow start, and we do not pace when tcp is ACK > clocked. All right. I think this clarifies a lot to me. I did not find this information anywhere though. I guess I need to go through the internals to find all the active features and possible working configurations. In short, by removing slow start + ack clocked phases, the mechanism avoids the cwnd-size line rate burst of packets which has a high probability to experience a big loss phenomenon somewhere along the path and maybe in the same local NIC, not necessarily in the user access bottleneck. This is something that happens in these days because of hardware assisted framing and very high speed NICs like what you mention. But 15 years ago none of those things existed and TCP did not push such huge bursts. In some cases I suspect no buffer today could accommodate such bursts and the loss would be almost sure. Then I wonder why hardware assisted framing implementations did not take into account that. I personally don't have the equipment to test in such cases but I see the phenomenon. Still, I believe that Savage's approach would have the merit to produce very small queues in the network (and all the benefits from that) but would be fragile, as reported, and require fq(_codel) in the network, at least in the access, to create incentives to do that pacing. > > Only when someones sets SO_MAX_PACING_RATE below the TCP rate, we can > eventually have all packets being paced, using TSO 'clusters' for TCP. > > > > On Thu, 2015-04-23 at 07:27 +0200, MUSCARIELLO Luca IMT/OLN wrote: >> one reference with pdf publicly available. On the website there are >> various papers >> on this topic. Others might me more relevant but I did not check all of >> them. >> Understanding the Performance of TCP Pacing, >> Amit Aggarwal, Stefan Savage, and Tom Anderson, >> IEEE INFOCOM 2000 Tel-Aviv, Israel, March 2000, pages 1157-1165. >> >> http://www.cs.ucsd.edu/~savage/papers/Infocom2000pacing.pdf > > . >