From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 8B7233B29E for ; Thu, 29 Nov 2018 18:27:51 -0500 (EST) Received: by mail-lj1-x232.google.com with SMTP id e5-v6so3340586lja.4 for ; Thu, 29 Nov 2018 15:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xnfTKGZ/wTjUuDwIjQyK/sRXb5SxBV4bxgCwKE7rFdg=; b=WT86lwA8cEEh2eWf6OH05LAuP4hHGsoAZcEd4vn0S1US/lJj+qbI8LiAlpQQAX8Bbn JbUF0SOqHUzdvbS3KYXsLPdTuAulNsSIgdBiMihv6qaINcB8k44m7qrZ0TAxEkUWd7Wv oBwLfPnxkwTnCMqF1jxFJ5899o/Wco5ZXHwspaFfQHIPpYinZcROBvyC3v7nnlBckbb1 HveFR6inO9WcZiriNOvffe6msfBnWD4du09l+m11R9YY5shjmmN5QsIfMF67G/9k0GDS Vy1XwNV84+54pK8WNpFUKIE+neSSzqWE36Hkd9uG64PXf9BIJowZZ2BHAnmFKsivgd+E XoGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xnfTKGZ/wTjUuDwIjQyK/sRXb5SxBV4bxgCwKE7rFdg=; b=pBU369XFnkKKS1MpkRFzXGm5Ry4jQDyXqoKZ+6tHeR0nRV3ZNjaI9TaOKKiWOQzx3h 56x1ptVqGZ52yRVbFTUgNQ69inF4TBEN/ijBwtmmOgVt13Zmaim34TZowTlds4PLpdB2 5x1U52PA9cofgcc3r95K9XhfgB6cbFKJgfQTpVL2ILURgF6H0OmvHUdTGolnb4MrYg9w AhwLnkgWNSKAioqe0DwbN/LO2CkiLhk8e+uV2c+e/YHxrXwd/N4+lcV6Z4ZR4whVGiP9 woaVGY5QH2pPifmXb7jxDjN1adnZU9w+hvG/+SwI1KjsghX435HNrJ8ssmylrzfPt+x6 gbXw== X-Gm-Message-State: AA+aEWYsTBxy8klS+//wCjyCUONWNi8mMhwOjmJvqLkAmLuDOb8Rau/T 5FAolrfIOrgIh7yHnyzninA= X-Google-Smtp-Source: AFSGD/U5ZOxQ5rZvy7qPM/dhEE2vrQJkZ/pi2BKvK+7yXE5uey/c7FQ4QO79cMcQ8Wv+XAQJAHl0ZQ== X-Received: by 2002:a2e:7615:: with SMTP id r21-v6mr2276954ljc.131.1543534070335; Thu, 29 Nov 2018 15:27:50 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-236-220-nat-p.elisa-mobile.fi. [83.245.236.220]) by smtp.gmail.com with ESMTPSA id d2sm529913lfg.16.2018.11.29.15.27.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Nov 2018 15:27:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Fri, 30 Nov 2018 01:27:47 +0200 Cc: Michael Welzl , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87va4gwe74.fsf@taht.net> <7125B446-F2C4-45B3-B48C-8720B1E35776@gmail.com> <7D833179-4D95-4C2F-B0AF-4FFD4D29DEE4@ifi.uio.no> <6025E3FF-E413-43F5-B9EB-4FC000846BE4@ifi.uio.no> <01A9062C-52DB-4FE8-A866-2796B2ADF88C@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 23:27:51 -0000 >> I have to ask, why would the network care? What optimisations can be = obtained by reordering packets *within* a flow, when it's usually just = as easy to deliver them in order? >=20 > Because most implementations aren't flow aware at all and might have 4 = queues, saying "oh, this single queue is for transports that don't care = about ordering" means everything in that queue can just be sent as soon = as it can, ignoring HOL caused by ARQ. Ah, so you're thinking in terms of link-layers which perform local = retransmission, like wifi. So the optimisation is to not delay packets = "behind" a corrupted packet while the latter is retransmitted. It's possible for a TCP to interpret a reordered packet as missing, = triggering an end-to-end retransmission which is then discovered to be = unnecessary. At the application level, TCP also performs the same HoL = blocking in response to missing data. So it's easy to see why links try = to preserve ordering, even to this extent, but I suspect they typically = do so on a per-station basis rather than per-flow. Personally I think the problem of reordering packets is overblown, and = that TCPs can cope with occasional missing or reordered packets without = serious consequences to performance. So if you add "reordering = tolerant" to the list of stuff that Diffserv can indicate, you might = just end up with all traffic being marked that way. Is that really = worthwhile? >> Of course, we already have FQ which reorders packets in *different* = flows. The benefits are obvious in that case. >=20 > FQ is a fringe in real life (speaking as a packet moving monkey). It's = just on this mailing list that it's the norm. Oddly enough, wifi is now one of the places where FQ is potentially = easiest to find, with Toke's work reaching the Linux kernel and so many = wifi routers being Linux based. An acknowledged problem is overly persistent retries by the ARQ = mechanism, such that the time horizon for the link-layer retransmission = often exceeds that of the end-to-end RTO, both for TCP and = request-response protocols like DNS. I say, retransmit at the link layer = once or twice, then give up and let the end-hosts sort it out. - Jonathan Morton