From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DE1833B29E for ; Thu, 29 Nov 2018 07:12:24 -0500 (EST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gSLB9-0004CQ-LG; Thu, 29 Nov 2018 13:12:23 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gSLB5-0006Om-T0; Thu, 29 Nov 2018 13:12:23 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: <7D833179-4D95-4C2F-B0AF-4FFD4D29DEE4@ifi.uio.no> Date: Thu, 29 Nov 2018 13:12:19 +0100 Cc: Jonathan Morton , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <6025E3FF-E413-43F5-B9EB-4FC000846BE4@ifi.uio.no> 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> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69158F79795936A10C525F525E31E3BFA40B9486 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 12:12:25 -0000 I'm answering myself with an add-on thought: > On 29 Nov 2018, at 09:08, Michael Welzl wrote: >=20 >=20 >=20 >> On 29 Nov 2018, at 08:46, Mikael Abrahamsson = wrote: >>=20 >> On Thu, 29 Nov 2018, Jonathan Morton wrote: >>=20 >>> In my view, that is the wrong approach. Better to improve Diffserv = to the point where it becomes useful in practice. >>=20 >> I agree, but unfortunately nobody has made me king of the Internet = yet so I can't just decree it into existance. >=20 > Well, for what you want (re-ordering tolerance), I would think that = the LE codepoint is suitable. From: > https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 > "there ought to be an expectation that packets of the LE PHB could be = excessively delayed or dropped when any other traffic is present" >=20 > ... I think it would be strange for an application to expect this, yet = not expect it to happen for only a few individual packets from a stream. Actually, maybe this is a problem: the semantics of LE are way broader = than "tolerant to re-ordering". What about applications that are = reordering-tolerant, yet still latency critical? E.g., if I use a protocol that can hand over messages out of order (e.g. = SCTP, and imagine it running over UDP if that helps), then the benefit = of this is typically to get messages delivered faster (without = receiver-side HOL blocking)). But then, wouldn't it be good to have a way to tell the network "I don't = care about ordering" ? It seems to me that we'd need a new codepoint for that. But, it also seems to me that this couldn't get standardised because = that standard would embrace a layer violation (caring about a transport = connection), even though that has been implemented for ages. :-( Cheers, Michael