From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 25FCC3B2A4 for ; Mon, 23 Apr 2018 19:31:46 -0400 (EDT) Received: by mail-lf0-x22a.google.com with SMTP id u21-v6so15873468lfu.9 for ; Mon, 23 Apr 2018 16:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kAz/LWi3QKN03DxzxcAqGBVXi639dbapKqq3edsVDdk=; b=Imgim5lGUHZoYTbN1FPwA+cQrh3FZmHmIe7cVmM+1pg9d8oXzPp7OxAiKLhZsBfvBU boQ4TtVKaGeIeSIxfaB6Xv/VyhtiAJyb9sQuLpVZXqwdRf4aMu5vrdxtZhX7Wx5wfgxv BvG/iPmwG9wAUDiLYfpNNUV67fvi9LGUE/hd1fwVB4ooW5SqJhleb/QYj8VZRO/jr9Rd 6M9nBQR7si/W+KG28XwVZKwHab2ArsSuW1LIOZ2KwBvJTpdYvIyL6Ckv7XvQ/ZtKw/tE 1om2ygJ4IAsJDKQTSwre8WG9xPoyMeKdthIOCAeXQCAi+H3CYENBaGMHMQ1epV4LYMWC gS5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kAz/LWi3QKN03DxzxcAqGBVXi639dbapKqq3edsVDdk=; b=cF6VdSGsz8avwr2pWXXiplxv/bfA+awLi8cvfEu2zF2dAhzdWnYdeHPMCvGbY77FRi mZwj4gmEtoQFmdmzDnxKkvhO7svKF8rTxMNDFn0tkeqJ2hW+1yBy9yoBYgV4Nb9fai10 GVmJS1O0qguc0WEFZfQEYQKX9MPqpB/SzfMiuhZdwSTfxmbhoJZ5iz/pdDMMmqsUuBsO MfFat0CkE+dD8wg02vMXXSqNk928NAYv+tVddVsXvAb3npI601hiOmrpna3VyOg6duSz 7jMaF+1UXoTE+Wdj0edc7ZbBWtMtIUGMc48wVrZbzQv2JXXTVH6+6GbiTBoEYxVZEBty 7ogQ== X-Gm-Message-State: ALQs6tD1ouj3nt3nWDuPduKEHa72kSZmf/sLnTW6PWljWIS/xxPpHJRs r7zyglNVunlHg7GRIEy9JlA= X-Google-Smtp-Source: AB8JxZpF4kEo9Jd2l8HXAIG/PoPK1Uge5C9buxsvsmdpI0U7bQYvVgvvY6a0suY7RzPWudIi3ToJsA== X-Received: by 10.46.93.87 with SMTP id r84mr7301097ljb.125.1524526304897; Mon, 23 Apr 2018 16:31:44 -0700 (PDT) Received: from [192.168.239.216] (83-245-234-255-nat-p.elisa-mobile.fi. [83.245.234.255]) by smtp.gmail.com with ESMTPSA id q142-v6sm3047399lfe.56.2018.04.23.16.31.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 16:31:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jonathan Morton In-Reply-To: Date: Tue, 24 Apr 2018 02:31:42 +0300 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <871sf6xqne.fsf@toke.dk> To: Pete Heist X-Mailer: Apple Mail (2.3445.6.18) Subject: Re: [Cake] Pre-print of Cake paper available 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: Mon, 23 Apr 2018 23:31:46 -0000 > - Thank you, I finally =E2=80=9Cget" triple-isolate. :) But I find it = easier to understand the behavior of dual-srchost and dual-dsthost, and = I think most would prefer its behavior, despite the fact that it needs = to be configured manually. Just a thought, knowing that cake currently = targets home gateways, and that there are now the egress and ingress = keywords, could host isolation default to dual-srchost for egress mode = and dual-dsthost for ingress mode? Or since using the keywords would be = fragile, is there a better way to know the proper sense for dual-srchost = and dual-dsthost? This is covered in the tc-cake manpage: .B dual-srchost .br Flows are defined by the 5-tuple, and fairness is applied first = over source addresses, then over individual flows. Good for use on egress = traffic from a LAN to the internet, where it'll prevent any one LAN host from monopolising the uplink, regardless of the number of flows they use. .PP .B dual-dsthost .br Flows are defined by the 5-tuple, and fairness is applied first = over destination addresses, then over individual flows. Good for use on = ingress traffic to a LAN from the internet, where it'll prevent any one LAN host = from monopolising the downlink, regardless of the number of flows they use. .PP I'm not terribly keen on overloading the ingress and egress keywords as = you suggest; certain people tend to get a bit worked up about it, and it = could be confusing unless done very carefully. Already, for the = command-line interface, we have to explain what "ingress" and "egress" = mean in themselves, when some of the target audience might have trouble = setting the clock on their VCR. (Also, they still have a VCR!) > - If =E2=80=98nat=E2=80=99 is not the default, won=E2=80=99t host = isolation not work by default for most home gateways, almost all of = which do nat? (Untested assumption.) Following on from the above, home gateways tend to have a GUI which can = be made to handle this sort of thing more intuitively. It helps GUI = programmers if the API is reasonably stable and orthogonal. > - Not in the paper, but is the =E2=80=98wash=E2=80=99 keyword really = needed? You'll have to ask Dave about that - he's the one who insists on having = it! The only coherent explanation I can immediately think of is to = bypass wifi's builtin medium-grant prioritisation. > - Is it worth mentioning that when the home gateway=E2=80=99s uplink = is WiFi, shaping is hard to do reliably, overhead and framing = compensation can=E2=80=99t even be implemented, and that this is all = more properly handled in the WiFi specific work? Wifi *or* 3G, etc. I'm very conscious of this problem, but it's hard to = solve in the qdisc itself. It's definitely better to solve it at the = upstream end of the link and with real-time medium awareness. Wifi can = have that today, with the right hardware, but good luck getting the = 2G/3G/4G vendors on side. Sensing the link rate via changes in flow latency is an attractive idea, = but there are subtleties which I haven't found a satisfactory solution = to yet. By nature, such an algorithm would need to be very conservative = and could not react quickly enough to guarantee QoS. - Jonathan Morton