From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 2278B3B29E for ; Sun, 3 Feb 2019 13:20:47 -0500 (EST) Received: by mail-qt1-x835.google.com with SMTP id e5so13183022qtr.12 for ; Sun, 03 Feb 2019 10:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KMFghh7R2HOQfk9n2aWGrhh1p6bKHbgNzwP7Nnt1goc=; b=FrKshhL3Zc3A8QfDb5hs2hINif7OzhIuYc/PQLt+R+SfojZA7jLH1k4SXBPRlqAQsU 0y6wQHxhHaygz1gQwHjKXBvDLymdJyhetOMv3633IESucKsKezjxt9YuttPeqQHtHWYp 4JN6UbBEkDaf7M61lAHoQqR4fY22VC76Aovw3KQGeVLDebwnTnO5aLcYFFfNuGJk0L7T /W+WG5EfKR58Sc1Axh9jHCc2ra6ZyaLS/l6t87HIBWdBPDf2bnJcADFbKaLn3nebNZcK BKz9Q7NxPx4ew5B/7nQwKwa7w5bJmRBypq9j9Ly/PwSt2xCw2uMXKQvJTgghyILu7Vhb F5cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KMFghh7R2HOQfk9n2aWGrhh1p6bKHbgNzwP7Nnt1goc=; b=B7F1CAI/BjEOX+6CR2cyW9Wnul8Ln1ZS4HSji2NOjFZ051CbGUt4bZIexXZXCXog5n 45huzAvV6M/ddd3XSfXT8872YwtbJo/8gMEtvaAfW+rH+RFubfKChD0UqcmiPBxBy7PD 87oJ2EIeSTlV47pAGHNhU9910ogkWW+H2LIDN1dNRZrShP9kPhqcxiJwP6/eCuyAqQ73 FwnlHr7ekZHkBhgFOeluY0qGLgFOQSsGTbVRRP+9RCjywXFq+4g+imnDgYIvAuMLeShr A3FOgWO/k+PIFgW0vrhTt7C08xt9XLLdG+a8QKoyOcwYWu0pa9XwhYDxDbBnudmeZTpY iuMQ== X-Gm-Message-State: AJcUukdNN2KmnSDy8it82wXJKCm+KbtWcHHRpYzx21PtzvUc83ix+yMa YgL6t9mzNOZz8hdy8tWnIg5u0DZGotNXhYAmsC8= X-Google-Smtp-Source: ALg8bN5yTLgqgCdmLI24XEAkDI+lqGQfptP1dM4+UDrcpjMcBCIYLEbxOW/oWPw3t+s3wGdpIqMNKvwghq7NAbDrpn8= X-Received: by 2002:a0c:aa56:: with SMTP id e22mr46223465qvb.158.1549218046630; Sun, 03 Feb 2019 10:20:46 -0800 (PST) MIME-Version: 1.0 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> <963ACC89-890D-4EA6-9E5E-1E7315F07C5A@gmail.com> <376C9A94-8EAA-4DCF-BFDC-ADA4E11A9FC7@ifi.uio.no> <5AC079FD-8DCF-4F3A-9E3B-BFFD3D1099E7@gmail.com> <60A508F7-9136-4E0F-A3FD-7CEF3A5724BF@ifi.uio.no> In-Reply-To: <60A508F7-9136-4E0F-A3FD-7CEF3A5724BF@ifi.uio.no> From: Dave Taht Date: Sun, 3 Feb 2019 10:20:07 -0800 Message-ID: To: Michael Welzl Cc: Jonathan Morton , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sun, 03 Feb 2019 18:20:47 -0000 I have to admit after reviewing the tattered mess of the l4s stuff, and the ongoing work in the tsvwg like the 40+ pager for dual queue https://datatracker.ietf.org/wg/tsvwg/documents/ the non-proposals here: https://datatracker.ietf.org/wg/l4s/documents/ that I'm finally inclined to make a go of jonathan's proposal for "some congestion experienced", as an incremental, backward compatible mechanism for the existing AQM deployments to provide an earlier signal than CE. Pluses are - 1 line of code to codel/fq_codel, basically replacing CE_THRESHOLD, easy to add to RTP/QUIC and other transports, transparent to all implementations I'm aware of (they should just ignore the change) a minus is retrofitting it to TCPs - as this is basically a receiver side optimization - is hard. On Thu, Nov 29, 2018 at 11:54 PM Michael Welzl wrote: > > > > > On 29 Nov 2018, at 13:52, Jonathan Morton wrote= : > > > >> On 29 Nov, 2018, at 2:06 pm, Michael Welzl wrote: > >> > >>> That's my proposal. > >> > >> - and it's an interesting one. Indeed, I wasn't aware that you're thin= king of a DCTCP-style signal from a string of packets. > >> > >> Of course, this is hard to get right - there are many possible flavour= s to ideas like this ... but yes, interesting! > > > > I'm glad you think so. Working title is ELR - Explicit Load Regulation= . > > > > As noted, this needs standardisation effort, which is a bit outside my = realm of experience - Cake was a great success, but relied entirely on expl= oiting existing standards to their logical conclusions. I think I started = writing some material to put in an I-D, but got distracted by something mor= e urgent. > > Well - "interesting" is one thing, "better than current proposals" is ano= ther... I guess this needs lots of evaluations before going anywhere. > > > > If there's an opportunity to coordinate with relevant people from simil= ar efforts, so much the better. I wonder, for example, whether the DCTCP f= olks would be open to supporting a more deployable version of their idea, o= r whether that would be a political non-starter for them. > > I'm not convinced (and I strongly doubt that they would be) that this wou= ld indeed be more deployable; your idea also includes TCP option changes, w= hich have their own deployment trouble... the L4S effort, to me, sounds "ea= sier" to deploy (which is not to say that it's easy to deploy at all; thou= gh I did like a recent conversation on possibly deploying it with a PEP... = that sounded quite doable to me). > > Cheers, > Michael > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740