Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Bob Briscoe <ietf@bobbriscoe.net> Mon, 25 March 2019 01:35 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CF2120219 for <tsvwg@ietfa.amsl.com>; Sun, 24 Mar 2019 18:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkj5oQBs6Joq for <tsvwg@ietfa.amsl.com>; Sun, 24 Mar 2019 18:35:07 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CDF120132 for <tsvwg@ietf.org>; Sun, 24 Mar 2019 18:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lTH6huzAqW1ogy58mMsfDggtw1Q2ZIYkIxzKUNDAIFg=; b=QlaqrDuj+E6OS3ypMyWX2vrHmY Ea05G6zwwebG3mGvu2stLaPGAz3LqF0Q90u5Jcz7uXrRTH+vkJkL8IkAilrV7nwWgL4Wt5zsSBPTc jZu10W4Q/sIgKDRrv6lCnzKO3enGRgBifHQ7bbRTYP3UXJrepDA+QOauU3/J8XfkPK+J+DXf2QpPV /SIC17AOb2xS26oe+P/Lk7x303NP2a3RSlYAqMZRQYQJ0eY5vmZdWGvM73xzLBk7Va4csTpoYxLmb pggZ36B0wFpsgO4YjOg8CtQA9LM5QNC4qvat+mVYnqmXxNsSNkqtmQB6UA1vad/kdKcLt6a3fGkqo UggPQm7g==;
Received: from 3.212.broadband18.iol.cz ([109.81.212.3]:18719 helo=[10.0.0.47]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1h8EW1-0006cv-JP; Mon, 25 Mar 2019 01:35:05 +0000
To: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
Cc: tsvwg IETF list <tsvwg@ietf.org>, bloat <bloat@lists.bufferbloat.net>
References: <d91a6a71-5898-9571-2a02-0d9d83839615@bobbriscoe.net> <CAA93jw5MTdn9EQgpZ0xrjqEi7UKqH3H_741anoB+pa0dtD=fpA@mail.gmail.com> <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <CAA93jw7jvjbZkEgO8xc03uCayo+o-uENxxAkzQOaz_EZSLhocw@mail.gmail.com> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <alpine.DEB.2.20.1903151915320.3161@uplift.swm.pp.se> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <CAHxHggfPCqf9biCDmHMqA38=4y6gY6pFtRVMjMrrzYfLyRBf-g@mail.gmail.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <AC14ACBB-A7CC-40E0-882C-2519D05ADC05@akamai.com> <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net> <1872521079.10187924.1553458515947@mail.yahoo.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <9188050f-dc71-0a23-5c2a-26639d90dfb5@bobbriscoe.net>
Date: Mon, 25 Mar 2019 02:34:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <1872521079.10187924.1553458515947@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WrfshFc2xAas5UuJo4lYUtJRUsM>
Subject: Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 01:35:09 -0000

Alex, inline...

On 24/03/2019 21:15, alex.burr@ealdwulf.org.uk wrote:
>
> Hi Bob,
>
>
> I note that all the non-dependent claims of US20170019343A1 (claims 1,14,22) seem to assume use of the proportional-integral controller (Note, I am not a lawyer, and especially not a patent lawyer).
Yes, as I understand it, Nokia's intention with this filing was to cover 
use of the PI controller in particular, in combination with various 
other ideas.

> In Appendix B of draft-briscoe-tsvwg-aqm-dualq-coupled, an alternate algorithm 'Curvy RED' seems to replace PI, but it is noted that 'the Curvy RED algorithm has not been maintained to the same degree as the DualPI2 algorithm '.
>
> Can you comment on whether the Curvy RED algorithm could form a non-patent-encumbered dualq? In particular:
>   - Why wasn't curvy red further developed? Was it found to contain some deficiency? Are you intending to present it as an alternative?
We just didn't develop it further, cos we were getting better results 
with PI2. However, I am aware of a hardware implementation based on 
Curvy RED going on at the moment, and you will see there have recently 
been review comments on that Curvy RED appendix on the list.

So, even tho PI might be better, Curvy RED (or another AQM) might be 
preferable for other reasons that performance (e.g. ease of 
implementation, or similarity to an existing hardware implementation).

And indeed, there's nothing to stop anyone using other AQMs, either to 
work round the IPR, or because they're preferable in their own right - 
the DualQ Coupled AQM is intentionally a framework into which you drop 2 
AQMs.

>   - Does Curvy RED actually completely replace PI?
Yes.
>   - Can we have reasonable assurance that no patents will surface covering Curvy RED?
Well, I developed the idea of Curvy RED and I / my employer (BT) did not 
file any IPR at the time. I got approval to publish a tech report 
jointly with Al-Lu. http://bobbriscoe.net/pubs.html#CRED-insights

That was May 2015, so given nothing has surfaced by now, there can't be 
anything from that time from us (where us = Al-Lu & BT).

Of course, I cannot guarantee that there is not another patent in the 
system from some other random company that my searches haven't found. 
There are large numbers of AQM patents. Also, I cannot guarantee that an 
implementer working now isn't filing patents around their 
implementation. All we can do is publish as much as possible as early as 
possible to try to keep some areas of the field open.


Bob
>
> Thanks,
> Alex
>
>
> On Wednesday, March 20, 2019, 11:29:38 PM GMT, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
>
>
>
>
>
> 1/ In 2016, I arranged for the hire of a patent attorney to undertake the unusual step of filing a third party observation with the European Patent Office. This went through Al-Lu's patent application claim by claim pointing to prior art and giving the patent examiner all the arguments to reject each claim. However, the examiner chose to take very little note of it, which was disappointing and costly for us. The main prior art is:
>      Gibbens, R.J. & Kelly, F.P., "On Packet Marking at Priority Queues," IEEE Transactions on Automatic Control 47(6):1016--1020 (June 2002)
> The guys named as inventors in AL-Lu's filing published a paper on PI2 with me, in which we included a citation of this Gibbens paper as inspiration for the coupling. The Gibbens paper was already cited as background by other patents, so the EPO has it in their citation index.
>
> The coupling was also based on my prior research with Mirja before I started working with the guys from Al-Lu in the RITE European Collaborative project. we had to go through a few rejections, but Mirja and I finally got this work published in 2014  - still before the priority date of the Al-Lu patent application:
>      Kühlewind, M., Wagner, D.P., Espinosa, J.M.R. & Briscoe, B., "Using Data Center TCP (DCTCP) in the Internet," In: Proc. Third IEEE Globecom Workshop on Telecommunications Standards: From Research to Standards pp.583-588 (December 2014)
>
> 2/ The only claim that I could not find prior art for (in the original EU filing) was a very specific claim about using a square root for the coupling. The Linux implementation runs this the other way round so that it only has to do a squaring. So I figured we were safe from that.
>
> However, until just now, I had not noticed that Al-Lu has retrospectively re-written the claims in the US patent and in the EU patent application to claim this the other way round - as a squaring. And to claim the two random number trick. Both restructuring to use a squaring and the two random number trick were definitely my ideas (while working for BT in a collaboration with Al-Lu). I have emails to prove this (from memory they were actually both in the same email). This is important, because a patent has to be about mechanism, not algorithm.
>
> 3/ This is a positive development. It means this patent is on very shaky legal ground. I have been trying to put pressure on Nokia to license this royalty free. But now I see what they have done, I am going to have to get a different type of legal advice.
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/