From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 978FD21F3E0; Sun, 10 May 2015 07:47:16 -0700 (PDT) Received: by labbd9 with SMTP id bd9so78710926lab.2; Sun, 10 May 2015 07:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MTY5HPJCRQ/2TX3/FsLSCa9/duQsF4xnhRnwYtfdoeY=; b=RlDH1tnY1TNKvVG3N/1U7Dtu9t/VSU8+lTNokmTDOZ1Tk+5b2FA4J3XE1Rpai+kIAF z13zBWGmP6UbbQn65qE1iL9fS8++yWh+0l7DbvIb+F2O2y3ACUCqGlM8MFbqQStashqa QDNIbchzlAbylsSUzoW2nrU4P7IGkdzJGV7vYB8TnUwcP9gB06wc2Pi7DJHFXU4s26Z/ nPisDyoq71Y2TYVEJjrIXFZKcV/ur2H9M3r1PwAtSmFEsg/ClaLbAsTgwNpc+mSN6h3F MxIkCWluDjmDTXkuy5u8vaDRqMwUngMCE1085v35vWlmaDTJTq2DI30V8n9DZLPK39Bg xLgw== X-Received: by 10.112.147.9 with SMTP id tg9mr4938985lbb.94.1431269227775; Sun, 10 May 2015 07:47:07 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-127-129.bb.dnainternet.fi. [188.67.127.129]) by mx.google.com with ESMTPSA id jr1sm2426018lbc.43.2015.05.10.07.46.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 May 2015 07:47:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Sun, 10 May 2015 17:46:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , bloat Subject: Re: [Codel] [Cake] Control theory and congestion control X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 14:47:52 -0000 > On 10 May, 2015, at 06:35, Dave Taht wrote: >=20 > New flows tend to be extremely bursty - and new flows in the real > world also tend to be pretty short, with 95% of all web traffic > fitting into a single IW10. There is some hope that HTTP/2 will reduce the prevalence of this = characteristic. It might take a while to reach full effect, due to how = much sharding there is right now, but I=E2=80=99m mildly optimistic - = it=E2=80=99s an application software change rather than at kernel level. = So there=E2=80=99ll be more flows spending more time in the = congestion-avoidance state than in slow-start. Meanwhile, I understand the reasons behind IW10, but it=E2=80=99s clear = that pacing those packets according to the RTT measured during the TCP = handshake is desirable. That *does* need kernel support, but it has the = fairly large benefit of not attempting to stuff ten packets into a = buffer at the same time. On drop-tail FIFOs, that inevitably leads to a = spike in induced latency (more so if several flows start up in parallel) = and a relatively high chance of burst loss, requiring retransmission of = some of those packets anyway. Aside from sch_fq, what support for TCP pacing is out there? > If e2e we know we are being FQ=C2=B4d=E2=80=A6 In general, E2E we don=E2=80=99t know what=E2=80=99s in the middle = unless we receive notice about it. Or unless we=E2=80=99re in a lab. - Jonathan Morton