From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5AB5C3CB3A for ; Wed, 17 Jul 2019 18:40:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563403225; bh=cKvPEH44w5kqd7aB4Xiia8/m7d0JkPUNQJe4u8axfGY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=h/MgQeC2OAL/UUHyT7b0k92wnENPAsyB9g7ncuG7/pfF5rjPGwGqdfzFuQgyTODFZ /yQn/Ml2OfpdE9/quCesRIS3PMrijX5UvhXHIKPEKfwCiq8ZDyl58EaLgxXRch9tzi EEEi4ynBbmHRtMzFU/Sd9rCcs6uG2tvkL+ohf0rk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.190.246.243]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcnRD-1iCBKw32FL-00k8Nf; Thu, 18 Jul 2019 00:40:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 18 Jul 2019 00:40:22 +0200 Cc: "Holland, Jake" , Jonathan Morton , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> To: "De Schepper, Koen (Nokia - BE/Antwerp)" X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:5vsz48WyuE5Bxqn/q0eWWx6UOY03a2F8CMP+jFb6euO6KZ0NJ+a a/0LwocQEeoPda+nH7D+uL4h0f+8l44LM8joIwLmIyRxq+f7vipLgU1S5scxiuRbnM/Fm6h b//yNE4pLOvM1PCBKl3wiZXU1Z2jNE7NH5MgRJkjC07pmQ0Vj5WiGiNTDBUpJebgdS3H0I9 EF5MNkAjvMSTskhupZq6w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:2lLh0MdSyKo=:nLntIou0dV4eoybXFSiw+k 6T+L/Tnww6+D8SO69pyQV7JuIELju+METTOVPiwi3RcWVHLJeeXqTf6dp6Vfq0bNnD5rnYa1d GIkmyUToJ3XNog17i5UazCB05p3YpbZU7t1r1p5WCOru0TSr+OyjCdNVd0MjQOW7F7jsdRc63 VZKh9QSB/kXBftZQP74i322KRl+EUEbNjvZGcbJe/6gg5vsqo/vwsM1C4daruENMT9UG3m27v Z4MfUnm7fzj8MHi6IkrqMGNm//K5bAG9gs58AKY5YgOKoB0aWPw7LF0CJfaagvu6sbxCvHeGs 9lrBfP7K1z5dCoM7B39Bwup0kY1RMBvdi+UdqNcb5uaF8v5pGKnuYs7GQ9HCv39Vzp8UrMMSP bsuCgL4gqekZYh7tKBgEyHMIC1jplp52vyuyDgaT67sBQU/QvC/72ZFuS0NW12LoflswEcomb 2wvqrHZhcsO/aTMoSjMqIiIht2/JRV1QLZWDnIIZ5thUCrXGfbeCY9glAOxSK+JgGdBITQOs0 p1Y/UTwK1S0lJ8wJZ2sZ/wa/JnU5jty0iRCvFF6jGyn5VFnkqlefsrYkw69OyGQa7ziFeuIuJ 77VypQN/Y7kJnt9HLNkgwl5KTkMdJeHk6tbJ7n7ERBAu4lkiLWYITSuGDg81SSxmpvARcr0MK 5iTkmhBEjDrDW0htb3DXx6m8cFtYHNyLnzefTTDQlidF3vmXQ9F9Tns018KENXzc5SY76im9b wAhdsMC+XMQIFZ5GMrHZLfwmQ89/58hO44TZBFwc2sfg4uIvN3+Dba5T8kG0gqBTjRmFKSVDG 2kFD+OuWwdKZFwDdGTwk00RUz4jNKUW3238d1b7K+5BgOoIrg436+vO3Tr1ziY/Zh/MKBF085 ZxqAUT5L0MtkqJg6wKR0SblR3LGo4w53IuSvlX0nuWw5Ft02B2f55j8V2ftrqTmw2kPZOnYaW YxlCqxKx9zscwyZYDew9bi/dAsWuWZ1L+3fqqdtYYmchLPJ2ydYwo17JrOyLrpC26KkDcKWOJ PsFWUdCtaf9wafpgKQSqDAEJ1E4GMEKsnx/6XOdAckNPL3xX5XF2rMguqSgAqa7b99xzZBAoM uC0ljiXwDfP1IA= Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts 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, 17 Jul 2019 22:40:35 -0000 Dear Koen, > On Jul 10, 2019, at 11:00, De Schepper, Koen (Nokia - BE/Antwerp) = wrote: [...] >>> Are you saying that even if a scalable FQ can be implemented in = high-volume aggregated links at the same cost and difficulty as dualq, = there's a reason not to use FQ? >=20 > FQ for "per-user" isolation in access equipment has clearly an extra = cost, not? If we need to implement FQ "per-flow" on top, we need 2 = levels of FQ (per-user and per-user-flow, so from thousands to millions = of queues). Also, I haven=E2=80=99t seen DC switches coming with an FQ = AQM... I believe there is work available demonstrating that a) millions = of concurrently active flows might be overly pessimistic (even for = peering routers) and b) IMHO it is far from settled that these bid = transit/peering routers will employ any of the the schemes we are = cooking up here. For b) I argue that both L4S "linear" CE-marking and = SCE linear ECT(1) marking will give a clear signal of overload that an = big ISP might not want to explicitly tell its customers... >=20 >>> Is there a use case where it's necessary to avoid strict isolation = if strict isolation can be accomplished as cheaply? >=20 > Even if as cheaply, as long as there is no reliable flow = identification, it clearly has side effects. Many homeworkers are using = a VPN tunnel, which is only one flow encapsulating maybe dozens. Fair enough, but why do you see a problem of treating this = multiplexed flow as different from any other flow, after all it was the = end-points conscious decision to masquerade as a single flow so why = assume special treatment; it is not that intermediate hops have any = insight into the multiplexing, so why expect them to cater for this? > Drop and ECN (if implemented correctly) are tunnel agnostic. Exactly, and that is true for each identified flow as well, so = fq does not diminish this, but rather builds on top of it. > Also how flows are identified might evolve (new transport protocols, = encapsulations, ...?). You are jesting surely, new protocols? We are in this kefuffle, = because you claim that a new protocol to signal linear CE-marking = response to be made of unobtaininum so you want to abuse an underused = EVN code point as a classifier. If new protocols are an option, just = bite the bullet and give tcp-reno a new protocol number and use this for = your L4S classifier; problem solved in a nice and clean fashion. > Also if strict flow isolation could be done correctly, it has = additional issues related to missed scheduling opportunities, Please elaborate, how an intermediate hop would know about the = desires of the endpoints here. As far as I can tell such hops have their = own ideas about optimal scheduling that they will enforce independent of = the what the endpoints deem optimal (by ncessity as most endpoints will = desire highest priority for their packets). [...] >>> Anyway, to me this discussion is about the tradeoffs between the 2 = proposals. It seems to me SCE has some safety advantages that should = not be thrown away lightly,=20 >=20 > I appreciate the efforts of trying to improve L4S, but nobody working = on L4S for years now see a way that SCE can work on a non-FQ system. That is a rather peculiar argument, especially given that both = you and Bob, major forces in the L4S approach, seemm to have = philosophical issues with fq? > For me (and I think many others) it is a no-go to only support FQ. = Unfortunately we only have half a bit free,=20 ??? Again you elaborately state the options in the L4S RFC and = just converge on the one which is most convenient, but also not the best = match for your requirements. > and we need to choose how to use it. Would you choose for the existing = ECN switches that cannot be upgraded (are there any?) or for all future = non-FQ systems. >=20 >>> so if the performance can be made equivalent, it would be good to = know about it before committing the codepoint. >=20 > The performance in FQ is clearly equivalent, but for a common-Q = behavior, only L4S can work. > As far as I understood the SCE-LFQ proposal is actually a slower FQ = implementation (an FQ in DualQ disguise =F0=9F=98=89), so I think not = really a better alternative than pure FQ. Also its single AQM on the = bulk queue will undo any isolation, as a coupled AQM is stronger than = any scheduler, including FQ. But how would the bulk queue actually care, being dedicated to = bulk flows? This basically just uses a single codel instance for all = flows in the bulk queue, exactly the situation codel was designed for, = if I recall correctly. Sure this will run into problems with = unrepsonsive flows, but not any more than DualQ with or without queue = protection (you can steer misbehaving flows into the the "classic" = queue, but this will just change which flows will suffer most of the = collateral damage of that unresponsive flow, IMHO). Best Regards Sebastian Moeller=