From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 139353CC07; Wed, 6 Apr 2016 13:16:24 -0400 (EDT) Received: by mail-lf0-x234.google.com with SMTP id g184so38880929lfb.3; Wed, 06 Apr 2016 10:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1ahNvd2Ow2SUcbs0O01COwlqVgHhjja19j5UzAc/N9E=; b=LHtn9P21u7We0LpCjNUxCC3RL7vijenLwdIFDLnGM+yA8bkr2OUc3jAn9Lgg26ODrM HnofQOoTKR8f1+JDD4KSd7wPKxHS2/RW15/gDFFQxRem0ENluiV/nYEVNLO4KTjFmDNo Sn9a5YlISs686Y7axh22HE8cbB6IJOyY1IDjWNC1KzW48t1UIKKJiAgHfpgj0zhUdi9T ie9pYdX5eXDSV9l0wtPjB9vBnR+1yG3L6pKJykxaSb22yK+YY94bskI/SvIgh4XYDwqc 9GyPKWrehIFiL+1csZkdbOtHbzm9QqCdRg0FIK45qJHSO5BiLrC+1Gby3CsK8MburVR5 erxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1ahNvd2Ow2SUcbs0O01COwlqVgHhjja19j5UzAc/N9E=; b=Kkc7mKuhkK0Bk0YhxWwG60Q2QGzL5dQB8wL2KxSTtLy7B3M736LevQFEXrVAx8dZ/s ybScnMRdxqjtfnHejWjXJ7Mh9FeCgRzIPmHbwynkXTTXb7cJ0dBlOVW0KW5cgsB/AqzA 11R+K5u9uT5DAFIoZDUaznX3j3u2b3o00X+7cdeIOKsaQivc9C2nqE0EAE8y1MUz5gZw EORWtweGRYuQYxwn8E/2ZgXwel4eGGumuN6oi2rTMKxFatfZSuHd0k4vyv0M8wzNqf5I D7RBHVPi1xdVwrCkBp+JvTQt1n2EweSzkREkJ6ozfT5m+0t7F3a0Wdqj7FKlRRU0MnnF HJTw== X-Gm-Message-State: AD7BkJI1ikkKH2GboiZrESrHWEOi7gxbdg9nR+Q5JvBZQXrLUD100DTnFb7qA/7cpUCUdg== X-Received: by 10.25.211.141 with SMTP id k135mr9719679lfg.164.1459962983909; Wed, 06 Apr 2016 10:16:23 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-67-252.bb.dnainternet.fi. [37.33.67.252]) by smtp.gmail.com with ESMTPSA id ai2sm589609lbc.46.2016.04.06.10.16.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 10:16:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: <5031EE38-920A-4B08-858A-5DC4302450AA@gmx.de> Date: Wed, 6 Apr 2016 20:16:00 +0300 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <3C097824-8754-4169-8FAB-7C802C2FB5D8@gmail.com> References: <2415E651-1852-4B48-A9B8-553D1A2507AE@gmail.com> <4A573483-5188-4893-82B3-721AEF527534@gmail.com> <5031EE38-920A-4B08-858A-5DC4302450AA@gmx.de> To: moeller0 X-Mailer: Apple Mail (2.3112) Subject: Re: [Cake] new code point proposed X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:16:25 -0000 > On 6 Apr, 2016, at 13:30, moeller0 wrote: >=20 >> Latency-sensitive traffic generally doesn=E2=80=99t use conventional = TCP, so the usual assumptions go out of the window. =20 >=20 > I fear this is not correct. Ssh is mostly using TCP and is latency = sensitive (to some degree), I agree that it would not be too well served = with LA though. SSH is not so latency-sensitive as to require =E2=80=9CLa=E2=80=9D = service; round-trip response times of a quarter second are acceptable, = though multiple seconds are not. With flow isolation, best-effort = service is sufficient. Even in the best-effort tin, Cake provides flow isolation and host = isolation, so any remaining latency (assuming we=E2=80=99re not in = severe overload) is self-induced by the flow itself. LLT, as I read it, = allows traffic to explicitly indicate that even self-induced latency is = unacceptable, using the =E2=80=9CLa=E2=80=9D codepoint. Hence the more = aggressive AQM setting. However, SSH will work quite happily in an =E2=80=9CLa=E2=80=9D class if = ECN is used. The marking rate may be high in some circumstances, but = packets will not be dropped, so application latency remains low. Some = applications may benefit from this behaviour. > Regarding UDP the challenge I see is to differentiate between = responsive and unresponsive flows. Which we fundamentally can=E2=80=99t do quickly enough to control the = queue to =E2=80=9CLa=E2=80=9D standards, so it=E2=80=99s not worth = trying for this purpose. So we should pessimistically assume that =E2=80=9CLa=E2=80=9D marked = traffic is unresponsive, and control all of it aggressively. Responsive = traffic which uses an =E2=80=9CLa=E2=80=9D mark will run at lower = throughput, which is exactly the expected tradeoff. > DCTCP will require much tighter target and interval settings anyway = and does not seem to be fit for the wider internet (with its assumption = of ZERO % ack packet loss). This is actually a very good point. DualQ is supposedly designed to = allow DCTCP to coexist with conventional traffic, and LLT is essentially = a spec for DualQ. But to maintain minimum latency for DCTCP, both the = forward and reverse paths need to be marked =E2=80=9CLa=E2=80=9D. So if = DCTCP really assumes zero reverse-path loss, it will incur a higher = round-trip delay due to the reverse path being marked =E2=80=9CLo=E2=80=9D= . I do sometimes wonder what those guys are smoking. - Jonathan Morton