Subject: Re: [iccrg] survey on Internet latency, FYI

From: Michael Welzl <[email-masked]>
Date: Mon, 4 Aug 2014 14:07:12 +0200

The link below doesn't work anymore; a slighly updated version is at:   http://riteproject.eu/?attachment_id=735

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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg

---

From: Dave Taht <[email-masked]>
Date: Mon, 4 Aug 2014 09:53:08 -0400

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

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

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Aug 2014 16:33:22 +0100

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:
> > This is a much-extended version 
> (understatement) of a position paper of ours
>Dave TÃ¤ht
>NSFW: 
>https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>Bloat mailing list
>[email-masked]
>https://lists.bufferbloat.net/listinfo/bloat

________________________________________________________________
Bob Briscoe,                                                  BT