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

[Alex Burr <ajb44.geo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5956 bytes --]

Bob,
 Thanks, this is interesting. As you probably know this patent has come to
the attention of the Linux community and caused some concern:
https://lwn.net/Articles/784125/
so it's useful to know of a potential workaround.

Alex

On Mon, Mar 25, 2019 at 1:34 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> 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/
>
>

[-- Attachment #2: Type: text/html, Size: 6948 bytes --]