From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3A5A93B260 for ; Fri, 20 May 2016 11:11:35 -0400 (EDT) Received: by mail-lb0-x22f.google.com with SMTP id ww9so36400882lbc.2 for ; Fri, 20 May 2016 08:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I/zyM3PUXROk7YnTWe713vbNjLMDCBnExoYzBdOHJNU=; b=BSd7CQi5bjJI4EBEoXccx1gdtRW1UR8MxCUQgAF02qOJw4R0bpaE4TYB6P8hKcGCsn qZoj/8EYA8tXFFErHqfosEL/++tFOAxF0n8jRHs28Bd7yvTGaemHge6EvIroR+I1TvxQ gLQobjGbEQurvPGMCooFUNhfYAb+F1YS1f3CjXVOleMlAI8Ag+Y5fCR5IdMVn2Ml1aCd oWBkfvIFXACuKlivhvlnTkj8I6vjq0KpfpAOiVi8ln8QmC9R3m90tRj9cWsD1qu088R6 QT6PBIvI0JDAhgwyg6ai7+8MdZbhR1ah/X4FhnWO309DNB+Qi7Cn17RMzlVd740v7ZSP FjyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I/zyM3PUXROk7YnTWe713vbNjLMDCBnExoYzBdOHJNU=; b=ec/cgIcaum2DHqDiGENKK0LGWeup7GDGOXNgwpuAyMj6uaHtfXqwIfbi0FxInGwfd9 ZlTo/7ziHDDPwXoJLpGaUPvinkRvIbjDagmgOJodT1I1V1/IHdqoYjif3V2NtPDTVGxR PcyOHsZ6kq6CA7ck7jal232o+eTC9I0fIAdrLC5Y80vjC0lMKd93Erg1xnmURz2Tl4ap ZiHFF0l/uHniy6+LY/60jZFJS1DKmsqato1OD5EkFb0JY9Vjx8GLxdwRZ1Z0jqF5Mm26 ZATfZq4VQdeQZC2JVnZ8jKCxEoBV6XJIFTLxdpcBQZyuvBrEuPs1QOqrD5NoGplqViXc dLJA== X-Gm-Message-State: AOPr4FXaUUioInk336Q5Zx8FurjzlG3cQ09/Zqt4DMWRFeLNyuNbsOD3N4u09NbQaQV1ZA== X-Received: by 10.112.169.65 with SMTP id ac1mr1302825lbc.92.1463757093359; Fri, 20 May 2016 08:11:33 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-138-144.bb.dnainternet.fi. [188.67.138.144]) by smtp.gmail.com with ESMTPSA id wt10sm3414808lbb.25.2016.05.20.08.11.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 08:11:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <3f1756f2-2f8a-d9f7-76cc-0036ee182a94@pollere.com> Date: Fri, 20 May 2016 18:11:29 +0300 Cc: codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <991C8B50-192E-431A-819F-F1C5954FF64F@gmx.de> <3f1756f2-2f8a-d9f7-76cc-0036ee182a94@pollere.com> To: Kathleen Nichols X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] [Cake] Proposing COBALT X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:11:35 -0000 > On 20 May, 2016, at 17:42, Kathleen Nichols = wrote: >=20 >> How big a problem is this in the real world? ARe we working on a >> theoretical problem, or something that is actually hurting people? >=20 > The above seems like it should be the FIRST thing to consider. Fragmented packets *are* a real-world problem, IMHO, in that iperf3 in = UDP mode produces lots of them by default, and hardware vendors tend to = use tools like iperf3 UDP (in a Faraday cage, no less) to demonstrate = the throughput of their new kit. Historically, that=E2=80=99s been the = method which produces the biggest and most impressive numbers, because = there is almost no reverse traffic contending for airtime. Currently fq_codel does a *really bad* job of showing high iperf3 UDP = numbers, even though it shows very good real-world TCP performance, and = that is likely to severely put off hardware vendors from deploying = fq_codel by default - because it=E2=80=99s not the TCP goodput numbers = that they like to use for marketing. And that=E2=80=99s a real-world problem when increasing AQM deployment = is a real-world goal. However, I think the relatively straightforward fix of isolating = fragmented packets (including the initial fragment, in which the = transport header remains visible) only by addresses should be = sufficient. This will keep the different parts of each packet together = (to the extent they were together on ingress) and allow more of them to = be successfully reassembled, allowing iperf3 to show numbers closer to = the no-AQM case. I=E2=80=99ve already described why it should be = sufficient for real-world traffic as well. Reassembling fragmented packets would also work, provided they are only = re-fragmented *after* passing through the qdisc, but carries dangers of = its own due to the resources required for reassembly. Presently those = costs are borne by the receiving host, which is in a better position to = do so. - Jonathan Morton