From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DE99A21F2AD for ; Mon, 13 Apr 2015 08:54:58 -0700 (PDT) Received: by oift201 with SMTP id t201so7860551oif.3 for ; Mon, 13 Apr 2015 08:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0Fzl9KtmI4fwCO/htdP8D3dpNL9vE3BHkIbtp8ZmcJQ=; b=jbgfIToUtndeC7WHjWzlyrWgYxGnrhWi5UDUCzU3VXYUp2xKGphmj41ICb8zGnDw7F K8cVZSbM4f/+RmIuvCr9Mtvp/sVbCbM000PFiHq8bblMSDCXEA+6zjTkTBPXJceTzh3C TkWFjUofK6SxbfA+ApMdsZPq2LVrkA3FL8+nHbwpu5hbYGJITaE/4vuxXkn11/lLHXgp MviCEmLC5thu6sx7tJr16jwWXotwo35jXzJONyBl8XaG42L90ZuHcBUv1Jx+Cj594kRS 6vOcmNy283qIJfmyzlfOh44/q4CKeegcOfOslrVldRoKTY59Ea/Md1w58i5rlPP599Vp DNxg== MIME-Version: 1.0 X-Received: by 10.202.216.87 with SMTP id p84mr7871632oig.133.1428940497746; Mon, 13 Apr 2015 08:54:57 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Mon, 13 Apr 2015 08:54:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Apr 2015 08:54:57 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake exploration X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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, 13 Apr 2015 15:55:27 -0000 On Sun, Apr 12, 2015 at 4:14 PM, Jonathan Morton wr= ote: > >> On 11 Apr, 2015, at 21:47, Dave Taht wrote: >> >> 14) strict priority queues. Some CBR techniques, notably IPTV, want 0 >> packet loss, but run at a rate determined by the provider to be below >> what the subscriber will use. Sharing that "fairly" will lead to loss >> of packets to those applications. >> >> I do not like strict priority queues. I would prefer, for example, >> that the CBR application be marked with ECN, and ignored, vs the the >> high probability someone will abuse a strict priority queue. > > The new priority mechanism in cake3 actually still supports a hard rate-l= imit function, albeit with a small amount of slop in it. You would simply = need to force the =E2=80=9Cbandwidth share=E2=80=9D quantum value to zero, = which would mean that the class involved only gets quanta when it=E2=80=99s= running within its limit. > > A sufficiently large =E2=80=9Cpriority share=E2=80=9D quantum value would= also behave an awful lot like strict priority. This is aided by the fact = that cake3 still charges the bandwidth of high priority classes to all lowe= r priority classes - but note that if the normal strictly-decreasing struct= ure of the classes is violated, it becomes possible to force some of the hi= gh-priority classes to operate permanently in bandwidth-sharing mode, robbi= ng them of most of their original benefit. > > I feel fairly strongly that this type of traffic should be handled in one= of two ways: > > - Mark it with an appropriate DSCP, such as CS3 or VA, and accept content= ion if it occurs. > > - Permanently mark off the CBR bandwidth as unavailable to normal traffic= , and configure cake to use the remainder; use a separate mechanism to have= the CBR traffic bypass cake. This would be particularly appropriate for a= shared broadcast stream. In the one IPTV case I have a grip on, it is a joined multicast stream, so it is not present when the tv is not active. How it is done in japan I do not know. Free.fr 's DSL device actually totally hides the the tv code on a different DSL vlan(ish) thing in the device driver, so the tv stream is not visible to the overlying qdisc at all, which I have no idea how to handle. > As a variation on the second option, it may be that the CBR stream is onl= y present intermittently. In that case, cake can be reconfigured on the fl= y by an external mechanism, to use either the full or reduced bandwidth; th= e bypass mechanism should remain in place meanwhile. Well, I perhaps misspoke about it being CBR. I would argue that in many cases it is VBR. > - Jonathan Morton > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67