From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D5C763CB37 for ; Wed, 7 Aug 2019 08:49:57 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C86BAB4; Wed, 7 Aug 2019 14:49:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1565182196; bh=HE/SaVF1ARHVdqMEVwNy2Rm5XWcTG6POBEpFxNGmBnA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ofhi4CFs+OMeyILIrNyry0PmzI4KOO9AJmcPIUJnquAe17mCuxs3io/1gkl6SNuSC gwdf0WfteAVrFwHPkBEoXbaLRC5tCdUSkD/8ouuRoydLAxun3PLL19lqompsm8sFHe bftHNNSgZ3rsX3F5gIPbkj+XJEJY6BycQnyH+vgY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C3863AF; Wed, 7 Aug 2019 14:49:56 +0200 (CEST) Date: Wed, 7 Aug 2019 14:49:56 +0200 (CEST) From: Mikael Abrahamsson To: Jeremy Harris cc: ecn-sane@lists.bufferbloat.net In-Reply-To: <80f8c4b0-02d8-9dd6-dcae-58d641497f23@wizmail.org> Message-ID: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> <34e3b1b0-3c4c-bb6a-82c1-89ac14d5fd2c@bobbriscoe.net> <77522c07-6f2e-2491-ba0e-cbef62aad194@bobbriscoe.net> <619092c0-640f-56c2-19c9-1cc486180c8b@bobbriscoe.net> <3A454B00-AEBC-48B6-9A8A-922C66E884A7@gmx.de> <21E40F44-2151-4565-970E-E1CEBE975036@gmx.de> <58F8052E-A56B-4E1F-8E1D-CBE75A0F7332@akamai.com> <9C42D7E8-734A-4620-B95B-5FFDDF1D3D95@gmail.com> <80f8c4b0-02d8-9dd6-dcae-58d641497f23@wizmail.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 12:49:58 -0000 On Wed, 7 Aug 2019, Jeremy Harris wrote: > I can't quite tell if you're noting that transports need to be aware of, > and handle (in one way or another) packets re-ordered by lower layers > [ I thought this was a given, already ] My statement here is that most if not all media is designed around delivering 5 tuple traffic in-order, and any out of order delivery is considered an anomily, and to be avoided. Juniper had a bug in one of their routers back in 2000 which would re-order 5-tuple flows occasionally. They were ridiculed by ISP peeps for years about this and it was kind of a scandal. We in the ISP business generally try really-really-really hard to deliver at least 5 tuple traffic in order. Most media try really really really hard to deliver the entire queue in order. For instance a mobile network typically will have a buffer that can hold many hundreds of packets, and it'll never re-order. It'll sit on a single packet being re-transmitted over and over again and hold the queue and nothing will be delivered until the entire queue ordering "promise" is met. So this is not 5-tuple, this is entire queue. All media I know of that has ARQ, for instance wifi, DOCSIS, *DSL, 3GPP networks, they all deliver the entire queue in-order. They'll hold up the entire queue if there is a single packet that needs several re-transmits to be delivered. So it's not uncommon to see packets being delivered in a very bursty fashion because there might have been 200 packets being held up for that single packet to be re-transmitted a few times, and it might not even have been in the same 5-tuple flow as any of those 200 packets. -- Mikael Abrahamsson email: swmike@swm.pp.se