From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 13:48:59 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD47AA50 for ; Tue, 12 Feb 2013 13:48:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 46E0934B for ; Tue, 12 Feb 2013 13:48:59 +0000 (UTC) Received: (qmail 37176 invoked from network); 12 Feb 2013 15:06:37 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Feb 2013 15:06:37 -0000 Message-ID: <511A4848.3070505@freebsd.org> Date: Tue, 12 Feb 2013 14:48:56 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> <5118D375.5000501@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , Alfred Perlstein , Randall Stewart , Kevin Oberman , net@freebsd.org, Andrey Zonov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:48:59 -0000 On 11.02.2013 19:56, Adrian Chadd wrote: > On 11 February 2013 03:18, Andre Oppermann wrote: > >> In general Google does provide quite a bit of data with their experiments >> showing that it isn't harmful and that it helps the case. >> >> Smaller RTO (1s) has become a RFC so there was very broad consensus in >> TCPM that is a good thing. We don't have it yet because we were not fully >> compliant in one case (loss of first segment). I've fixed that a while >> back and will bring 1s RTO soon to HEAD. >> >> I'm pretty sure that Google doesn't ignore idle on their Internet facing >> servers. They may have proposed a decay mechanism in the past. I'd have >> to check the TCPM archives for that. > > Argh, the "If google does, it it must be fine" argument. Please. You removed what I was replying to. There is no doubt IW10 originated from Google. However Google took it to TCPM and provided measurement data with it. After some forth and back they provided more data which began to convince more people on TCPM. Eventually the proposal was adopted as official TCPM working group draft and likely will become a RFC later this year. If you want to argue against RTO1s (RFC6298) then the lead authors are from ICSI/UC Berkeley. Google did participate in that one by providing additional measurement data. > Does Google publish the data for these experiments with the > international and local links broken down? Yes. Have you followed the evolution and discussion of IW10 on TCPM? > Google run a highly distributed infrastructure (this isn't news for > anyone, I know) and thus the link distance, RTT, number of hops, etc > may not accurately reflect "the internet". It may accurately reflect > "the internet from the perspective of being roughly within the same > city or state" in a lot of cases. > > The TCP congestion algorithms aren't just for avoiding congestion over > a peering fabric and last-mile ISP infrastructure. IW10 is not a congestion control algorithm. It is a change to the initial state of it at the beginning of an connection when not much other data is available. Many years ago the same thing happend with RFC3390 which increased the IW to 3 segments. > The effects of tweaking congestion algorithms for delivery over a > local peering infrastructure where you try to run things as > un-congested as possible (where congestion is now The ISPs Problem) > where you maintain tight control over as much of the network > infrastructure as you can is likely going to be very different to the > congestion algorithm behaviour needed for some end-node speaking to a > variety of end-nodes over a longer, more varying set of international > links. You know, what TCP congestion algorithms are also trying to > "play fair" with. I agree but not relevant to this case. > Please - as much as I applaud Google for what they do, please don't > generalise their results to "the greater internet" without looking at > the many caveats/assumptions. Well, that's exactly what I'm trying to do here. Except not only for ideas sourced from Google but also other places. Like "it's in Linux and the Internet hasn't broken down yet". Without any measurement date whatsoever. -- Andre