Dave,

Thx for BQL+pFabric+HFSC suggestions. We are now in the process of addressing a few items the reviewers wanted us to change (each different from yours)), so we can add stuff. The main reason for sending out the pre-print was precisely to widen the formal review process out to the community, so thx for contributing.

All we hoped for was to ensure we had representative papers about each /type/ of technology. We knew we could never summarise every paper that has every been written about latency, altho obviously we do want to include as many /important/ ones as possible.

I'm afraid we have no plans to turn this into a living doc. It would be feasible if it was just a categorisation of paper summaries. However, the main value of the paper (IMO) is the quantative comparison of the main techniques (Gain vs Pain section), which isn't so easy to open up to public contribution. Even amongst our 10 authors, it took a long while to converge on the answer for each technology we picked. Now all the authors want to get on with the rest of their lives.


Bob

At 14:53 04/08/2014, Dave Taht wrote:
On Mon, Aug 4, 2014 at 8:07 AM, Michael Welzl <mich...@ifi.uio.no> wrote:
> The link below doesn't work anymore; a slighly updated version is at:
> http://riteproject.eu/?attachment_id=735

0) I enjoyed reading it, but it wasn't as comprehensive as I'd like,
and more than a few paragraphs reflected a bias that I'd have liked to
have had an opportunity to address before publication.

1) I would like a future version to dedicate a bit of space to "Byte
Queue Limits" (BQL), as that happens to have been the technology that
has made all the AQM and FQ algorithms scalable to 10s of gbits in
Linux. Prior to BQL, NO aqm or FQ worked right at line rate. I have
kept hoping some paper would examine the difference in latency due to
BQL for quite some time now... if it wasn't for the BQL breakthrough:

https://lists.bufferbloat.net/pipermail/bloat/2011-November/000726.html

The bufferbloat.net project would have folded up shop and quit that
year, if BQL hadn't arrived, as our initial focus on fixing wifi
wasn't working out.

The BQL concept and implementation are delightfully simple and fast
enough to run at interrupt cleanup time.

 http://lwn.net/Articles/454390/

And the results, spectacular, particularly on hosts with TSO or GSO
enabled, and at a wide range of rates, particularly high ones.

2) The same person that did Data Center TCP went off to do pfabric. I
don't see that in here.

3) Also HFSC seems to be widely used, in the DSL market in particular,
and is not in here.

4) Numerous other nits. I do hope further input from the community is
solicited for a 1.1, and I'd love it if it were available as a wiki or
html document one day for easier browsing/decoding/searching from the
Internet.


>
> On 21. juli 2014, at 11:17, David Ros wrote:
>
> Hi all,
>
> The following paper may be of interest to ICCRGers:
>
> "Reducing Internet Latency: A Survey of Techniques and their Merits"
>
> available here:
> http://riteproject.files.wordpress.com/2014/07/latency_preprint-31.pdf
>
> This is a much-extended version (understatement) of a position paper of ours
> that was presented in last year's ISOC workshop on Internet latency.
>
> It's currently under submission to a journal, so this preprint will be
> slightly amended for the eventual journal version that in principle should
> be available in a few months. Comments will be gladly welcome.
>
> Thanks,
>
> David (as individual, on behalf of all the authors)
>
> _______________________________________________
> iccrg mailing list
> ic...@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg
>
>
>
> _______________________________________________
> iccrg mailing list
> ic...@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg
>



--
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

________________________________________________________________
Bob Briscoe, BT
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to