Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed]

The assumption that each flow on a path has a minimum, stable  RTT fails in wireless and multi path networks.



However, it's worth remembering two things: buffering above a certain level is never an improvement, and flows through any shared router come and go quite frequently on the real Internet.

Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking is far better and packet drops are required for bounding time to recover after congestion failure.

The authors suffer from typical naivete by thinking all flows are for file transfer and that file transfer throughput is the right basic perspective, rather than end to end latency/jitter due to sharing, and fair sharing stability.




-----Original Message-----
From: "Jonathan Morton" <chromatix99@gmail.com>
Sent: Sat, Sep 17, 2016 at 4:11 pm
To: "Maciej Soltysiak" <maciej@soltysiak.com>
Cc: "Maciej Soltysiak" <maciej@soltysiak.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next


> On 17 Sep, 2016, at 21:34, Maciej Soltysiak  wrote:
> 
> Cake and fq_codel work on all packets and aim to signal packet loss early to network stacks by dropping; BBR works on TCP and aims to prevent packet loss. 

By dropping, *or* by ECN marking.  The latter avoids packet loss.

 - Jonathan Morton

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[Dave Taht]

On Sat, Sep 17, 2016 at 2:11 PM,  <dpreed@reed.com> wrote:
> The assumption that each flow on a path has a minimum, stable  RTT fails in wireless and multi path networks.

Yep. But we're getting somewhere serious on having stabler RTTs for
wifi, and achieving airtime fairness.

http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png

>
>
>
> However, it's worth remembering two things: buffering above a certain level is never an improvement,

which BBR recognizes by breaking things up into separate bandwidth and
RTT analysis phases.

>and flows through any shared router come and go quite frequently on the real Internet.

Very much why I remain an advocate of fq on the routers is that your
congestion algorithm for your particular flow gets more independent of
the other flows, and ~0 latency and jitter for sparse flows is
meaningful.

> Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking is far better and packet drops are required for bounding time to recover after congestion failure.

Aww, give the code a chance, it's only been public for a day! I
haven't even got it to compile yet!

I think it is a *vast* improvement over cubic, and possibly the first delay
sensitive tcp that can compete effectively with it. I'm dying to test
it thoroughly,
but have a whole bunch other patches for wifi in my queue.

>
> The authors suffer from typical naivete by thinking all flows are for file transfer and that file transfer throughput is the right basic perspective, rather than end to end latency/jitter due to sharing, and fair sharing stability.

While I agree *strongly* that lots of short flows is how the internet
mostly operates, (I used to cite a paper on this a lot)

a huge number of bulk flows exist that has been messing up the short
flows. I think the number was something 70% of internet traffic has
become netflix-like. *anything* e2e that can reduce the negative
impact of the big fat flows on everything else is a win.


>
>
>
> -----Original Message-----
> From: "Jonathan Morton" <chromatix99@gmail.com>
> Sent: Sat, Sep 17, 2016 at 4:11 pm
> To: "Maciej Soltysiak" <maciej@soltysiak.com>
> Cc: "Maciej Soltysiak" <maciej@soltysiak.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next
>
>
>> On 17 Sep, 2016, at 21:34, Maciej Soltysiak  wrote:
>>
>> Cake and fq_codel work on all packets and aim to signal packet loss early to network stacks by dropping; BBR works on TCP and aims to prevent packet loss.
>
> By dropping, *or* by ECN marking.  The latter avoids packet loss.
>
>  - Jonathan Morton
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[Dave Taht]

ok, I got BBR built with net-next + v2 of the BBR patch. If anyone
wants .deb files for ubuntu, I can put them up somewhere. Some quick
results:

http://blog.cerowrt.org/post/bbrs_basic_beauty/

I haven't got around to testing cubic vs bbr in a drop tail
environment, my take on matters is with fq (fq_codel) in place, bbr
will work beautifully against cubic, and I just wanted to enjoy the
good bits for a while before tearing apart the bad... and staying on
fixing wifi.

I had to go and rip out all the wifi patches to get here... as some
code landed to the ath10k that looks to break everything there, so
need to test that as a baseline first - and I wanted to see if
sch_fq+bbr did anything to make the existing ath9k driver work any
better.




On Sat, Sep 17, 2016 at 2:33 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Sep 17, 2016 at 2:11 PM,  <dpreed@reed.com> wrote:
>> The assumption that each flow on a path has a minimum, stable  RTT fails in wireless and multi path networks.
>
> Yep. But we're getting somewhere serious on having stabler RTTs for
> wifi, and achieving airtime fairness.
>
> http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png
>
>>
>>
>>
>> However, it's worth remembering two things: buffering above a certain level is never an improvement,
>
> which BBR recognizes by breaking things up into separate bandwidth and
> RTT analysis phases.
>
>>and flows through any shared router come and go quite frequently on the real Internet.
>
> Very much why I remain an advocate of fq on the routers is that your
> congestion algorithm for your particular flow gets more independent of
> the other flows, and ~0 latency and jitter for sparse flows is
> meaningful.
>
>> Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking is far better and packet drops are required for bounding time to recover after congestion failure.
>
> Aww, give the code a chance, it's only been public for a day! I
> haven't even got it to compile yet!
>
> I think it is a *vast* improvement over cubic, and possibly the first delay
> sensitive tcp that can compete effectively with it. I'm dying to test
> it thoroughly,
> but have a whole bunch other patches for wifi in my queue.
>
>>
>> The authors suffer from typical naivete by thinking all flows are for file transfer and that file transfer throughput is the right basic perspective, rather than end to end latency/jitter due to sharing, and fair sharing stability.
>
> While I agree *strongly* that lots of short flows is how the internet
> mostly operates, (I used to cite a paper on this a lot)
>
> a huge number of bulk flows exist that has been messing up the short
> flows. I think the number was something 70% of internet traffic has
> become netflix-like. *anything* e2e that can reduce the negative
> impact of the big fat flows on everything else is a win.
>
>
>>
>>
>>
>> -----Original Message-----
>> From: "Jonathan Morton" <chromatix99@gmail.com>
>> Sent: Sat, Sep 17, 2016 at 4:11 pm
>> To: "Maciej Soltysiak" <maciej@soltysiak.com>
>> Cc: "Maciej Soltysiak" <maciej@soltysiak.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
>> Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next
>>
>>
>>> On 17 Sep, 2016, at 21:34, Maciej Soltysiak  wrote:
>>>
>>> Cake and fq_codel work on all packets and aim to signal packet loss early to network stacks by dropping; BBR works on TCP and aims to prevent packet loss.
>>
>> By dropping, *or* by ECN marking.  The latter avoids packet loss.
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed]

I constantly see the claim that >50% of transmitted data on the Internet are streaming TV. However, the source seems to be as hard to nail down as the original claim that >50% of Internet traffic was pirated music being sent over bittorrent.

You recently repeated that statistic as if it were a verified fact.

I remember that in the early days of WiFi DSSS availability the claim was repeatedly made from podiums at conferences I attended that "the amount of WiFi in parking lots on Sand Hill Road [then the location of most major Silicon Valley VC firms] had made it so that people could not open their car doors with their remote keys".  This was not intended as hyperbole or a joke - I got into the habit of asking the speakers how they knew this, and they told me that their VC friends had all had it happen to them...

Propaganda consists of clever stories that "sound plausible" and which are spread by people because they seem to support something they *wish* were true for some reason.

I suspect that this 70% number is more propaganda of this sort.

In case it is not obvious, the beneficiaries of this particular propaganda are those who want to claim various things - that the Internet is now just TV broadcasting and thus should be treated that way (Internet Access Providers should select "channels", charge for allowing them through to customers, improving the "quality of programming" and censoring anything offensive, as just one example)

So I am extremely curious as to an actual source of such a number, how it was measured, and how its validity can be tested reproducibly.

Some may remember that the original discovery of "bufferbloat" was due to the fact that Comcast deployed Sandvine gear in its network to send RST packets for any connections that involved multiple concurrent TCP uploads (using DPI technology to guess what TCP connections to RST and the right header data to put on the RST packets).

Their argument for why they *had* to do that was that they "had data" that said that their network was being overwhelmed by bittorrent pirates.

In fact, the problem was bufferbloat - DOCSIS 2.0 gear that was designed to fail miserably under any intense upload.  The part about bittorrent piracy was based on claimed measurements that apparently were never in fact performed about the type of packets that were causing the problem.

Hence: I know it is a quixotic thing on my part, but the scientist in me wants to see the raw data and see the methods used to obtain it.

I have friends who actually measure Internet traffic (kc claffy, for example), and they do a darn good job.  The difficulty in getting data that could provide the 70% statistic is *so high* that it seems highly likely that no such measurement has ever been done, in fact.

But if someone has done such a measurement (directly or indirectly), defining their terms and methodology sufficiently so that it is a reproducible result, it would probably merit an award for technical excellence.

Otherwise, please, please, please don't lend your name to promulgating nonsense, even if it seems useful to argue your case.  Verify your sources.



On Monday, September 19, 2016 4:26pm, "Dave Taht" <dave.taht@gmail.com> said:

> ok, I got BBR built with net-next + v2 of the BBR patch. If anyone
> wants .deb files for ubuntu, I can put them up somewhere. Some quick
> results:
> 
> http://blog.cerowrt.org/post/bbrs_basic_beauty/
> 
> I haven't got around to testing cubic vs bbr in a drop tail
> environment, my take on matters is with fq (fq_codel) in place, bbr
> will work beautifully against cubic, and I just wanted to enjoy the
> good bits for a while before tearing apart the bad... and staying on
> fixing wifi.
> 
> I had to go and rip out all the wifi patches to get here... as some
> code landed to the ath10k that looks to break everything there, so
> need to test that as a baseline first - and I wanted to see if
> sch_fq+bbr did anything to make the existing ath9k driver work any
> better.
> 
> 
> 
> 
> On Sat, Sep 17, 2016 at 2:33 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> On Sat, Sep 17, 2016 at 2:11 PM,  <dpreed@reed.com> wrote:
>>> The assumption that each flow on a path has a minimum, stable  RTT fails in
>>> wireless and multi path networks.
>>
>> Yep. But we're getting somewhere serious on having stabler RTTs for
>> wifi, and achieving airtime fairness.
>>
>> http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png
>>
>>>
>>>
>>>
>>> However, it's worth remembering two things: buffering above a certain level is
>>> never an improvement,
>>
>> which BBR recognizes by breaking things up into separate bandwidth and
>> RTT analysis phases.
>>
>>>and flows through any shared router come and go quite frequently on the real
>>> Internet.
>>
>> Very much why I remain an advocate of fq on the routers is that your
>> congestion algorithm for your particular flow gets more independent of
>> the other flows, and ~0 latency and jitter for sparse flows is
>> meaningful.
>>
>>> Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking
>>> is far better and packet drops are required for bounding time to recover after
>>> congestion failure.
>>
>> Aww, give the code a chance, it's only been public for a day! I
>> haven't even got it to compile yet!
>>
>> I think it is a *vast* improvement over cubic, and possibly the first delay
>> sensitive tcp that can compete effectively with it. I'm dying to test
>> it thoroughly,
>> but have a whole bunch other patches for wifi in my queue.
>>
>>>
>>> The authors suffer from typical naivete by thinking all flows are for file
>>> transfer and that file transfer throughput is the right basic perspective,
>>> rather than end to end latency/jitter due to sharing, and fair sharing
>>> stability.
>>
>> While I agree *strongly* that lots of short flows is how the internet
>> mostly operates, (I used to cite a paper on this a lot)
>>
>> a huge number of bulk flows exist that has been messing up the short
>> flows. I think the number was something 70% of internet traffic has
>> become netflix-like. *anything* e2e that can reduce the negative
>> impact of the big fat flows on everything else is a win.
>>
>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: "Jonathan Morton" <chromatix99@gmail.com>
>>> Sent: Sat, Sep 17, 2016 at 4:11 pm
>>> To: "Maciej Soltysiak" <maciej@soltysiak.com>
>>> Cc: "Maciej Soltysiak" <maciej@soltysiak.com>,
>>> "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
>>> Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP
>>> innet-next
>>>
>>>
>>>> On 17 Sep, 2016, at 21:34, Maciej Soltysiak  wrote:
>>>>
>>>> Cake and fq_codel work on all packets and aim to signal packet loss early to
>>>> network stacks by dropping; BBR works on TCP and aims to prevent packet loss.
>>>
>>> By dropping, *or* by ECN marking.  The latter avoids packet loss.
>>>
>>>  - Jonathan Morton
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> http://blog.cerowrt.org
> 
> 
> 
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
>

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[Mikael Abrahamsson]

On Tue, 20 Sep 2016, dpreed@reed.com wrote:

> I constantly see the claim that >50% of transmitted data on the Internet 
> are streaming TV. However, the source seems to be as hard to nail down 
> as the original claim that >50% of Internet traffic was pirated music 
> being sent over bittorrent.

It's my firm opinion that in the past 5-15 years (depending on market), 
more than 50% of Internet traffic is video, in some form or another.

This is from working at ISPs and seeing where traffic went. First it was 
bitorrent (pirated video), now it's Youtube, Netflix and other kind of 
streaming video. I wouldn't call this "TV" though.

In my household (2 adults, 1 6 year old), 75% of the average weekly 
traffic by volume, is over IPv6. I haven't checked in detail, but my guess 
is that Youtube+Netflix is the majority of this traffic. I come to this 
conclusion by looking at when the traffic occurs and what the traffic 
levels are, and from remembering what was done at the time.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed]

bittorrent is a kind of "FTP" rather than semi-isochornous (i.e. rate-bounded) "TV" in my personal classification.  As I'm sure you know, the two are quite different in their effects on congestion and their handling of congestion.

The idea that bittorrent dominated the Internet traffic volume at any point in time in the past is just plain not credible.  And an observation of one's own personal household by a high-end network user is not extrapolatable at scale.

(for example, it would require that all enterprise traffic through the Internet be dominated by bittorrent, unless enterprise traffic on the Internet is insignificant. There were never significant bittorrent users in enterprises, either connecting out from the companies' networks, or connecting "in" to the companies' externally facing sites).

In any case, there is no scienfic validity to "I seem to remember" claims.





On Wednesday, September 21, 2016 2:24am, "Mikael Abrahamsson" <swmike@swm.pp.se> said:

> On Tue, 20 Sep 2016, dpreed@reed.com wrote:
> 
>> I constantly see the claim that >50% of transmitted data on the Internet
>> are streaming TV. However, the source seems to be as hard to nail down
>> as the original claim that >50% of Internet traffic was pirated music
>> being sent over bittorrent.
> 
> It's my firm opinion that in the past 5-15 years (depending on market),
> more than 50% of Internet traffic is video, in some form or another.
> 
> This is from working at ISPs and seeing where traffic went. First it was
> bitorrent (pirated video), now it's Youtube, Netflix and other kind of
> streaming video. I wouldn't call this "TV" though.
> 
> In my household (2 adults, 1 6 year old), 75% of the average weekly
> traffic by volume, is over IPv6. I haven't checked in detail, but my guess
> is that Youtube+Netflix is the majority of this traffic. I come to this
> conclusion by looking at when the traffic occurs and what the traffic
> levels are, and from remembering what was done at the time.
> 
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[Alan Jenkins]

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

On 20/09/16 21:27, dpreed@reed.com wrote:
> I constantly see the claim that >50% of transmitted data on the Internet are streaming TV. However, the source seems to be as hard to nail down

I don't think the source is hard to identify.  It's Sandvine press 
releases.  That's what the periodic stories on Ars Technica are always 
derived from.

https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-traffic-is-now-streaming-video-and-audio.html

>   as the original claim that >50% of Internet traffic was pirated music being sent over bittorrent.
>
> You recently repeated that statistic as if it were a verified fact.
>
> I remember that in the early days of WiFi DSSS availability the claim was repeatedly made from podiums at conferences I attended that "the amount of WiFi in parking lots on Sand Hill Road [then the location of most major Silicon Valley VC firms] had made it so that people could not open their car doors with their remote keys".  This was not intended as hyperbole or a joke - I got into the habit of asking the speakers how they knew this, and they told me that their VC friends had all had it happen to them...
>
> Propaganda consists of clever stories that "sound plausible" and which are spread by people because they seem to support something they *wish* were true for some reason.
>
> I suspect that this 70% number is more propaganda of this sort.
>
> In case it is not obvious, the beneficiaries of this particular propaganda are those who want to claim various things - that the Internet is now just TV broadcasting and thus should be treated that way (Internet Access Providers should select "channels", charge for allowing them through to customers, improving the "quality of programming" and censoring anything offensive, as just one example)
>
> So I am extremely curious as to an actual source of such a number, how it was measured, and how its validity can be tested reproducibly.
>
> Some may remember that the original discovery of "bufferbloat" was due to the fact that Comcast deployed Sandvine gear in its network to send RST packets for any connections that involved multiple concurrent TCP uploads (using DPI technology to guess what TCP connections to RST and the right header data to put on the RST packets).
>
> Their argument for why they *had* to do that was that they "had data" that said that their network was being overwhelmed by bittorrent pirates.
>
> In fact, the problem was bufferbloat - DOCSIS 2.0 gear that was designed to fail miserably under any intense upload.  The part about bittorrent piracy was based on claimed measurements that apparently were never in fact performed about the type of packets that were causing the problem.
>
> Hence: I know it is a quixotic thing on my part, but the scientist in me wants to see the raw data and see the methods used to obtain it.
>
> I have friends who actually measure Internet traffic (kc claffy, for example), and they do a darn good job.  The difficulty in getting data that could provide the 70% statistic is *so high* that it seems highly likely that no such measurement has ever been done, in fact.
>
> But if someone has done such a measurement (directly or indirectly), defining their terms and methodology sufficiently so that it is a reproducible result, it would probably merit an award for technical excellence.
>
> Otherwise, please, please, please don't lend your name to promulgating nonsense, even if it seems useful to argue your case.  Verify your sources.
>
>
>
> On Monday, September 19, 2016 4:26pm, "Dave Taht" <dave.taht@gmail.com> said:
>
>> ok, I got BBR built with net-next + v2 of the BBR patch. If anyone
>> wants .deb files for ubuntu, I can put them up somewhere. Some quick
>> results:
>>
>> http://blog.cerowrt.org/post/bbrs_basic_beauty/
>>
>> I haven't got around to testing cubic vs bbr in a drop tail
>> environment, my take on matters is with fq (fq_codel) in place, bbr
>> will work beautifully against cubic, and I just wanted to enjoy the
>> good bits for a while before tearing apart the bad... and staying on
>> fixing wifi.
>>
>> I had to go and rip out all the wifi patches to get here... as some
>> code landed to the ath10k that looks to break everything there, so
>> need to test that as a baseline first - and I wanted to see if
>> sch_fq+bbr did anything to make the existing ath9k driver work any
>> better.
>>
>>
>>
>>
>> On Sat, Sep 17, 2016 at 2:33 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>> On Sat, Sep 17, 2016 at 2:11 PM,  <dpreed@reed.com> wrote:
>>>> The assumption that each flow on a path has a minimum, stable  RTT fails in
>>>> wireless and multi path networks.
>>> Yep. But we're getting somewhere serious on having stabler RTTs for
>>> wifi, and achieving airtime fairness.
>>>
>>> http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png
>>>
>>>>
>>>>
>>>> However, it's worth remembering two things: buffering above a certain level is
>>>> never an improvement,
>>> which BBR recognizes by breaking things up into separate bandwidth and
>>> RTT analysis phases.
>>>
>>>> and flows through any shared router come and go quite frequently on the real
>>>> Internet.
>>> Very much why I remain an advocate of fq on the routers is that your
>>> congestion algorithm for your particular flow gets more independent of
>>> the other flows, and ~0 latency and jitter for sparse flows is
>>> meaningful.
>>>
>>>> Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking
>>>> is far better and packet drops are required for bounding time to recover after
>>>> congestion failure.
>>> Aww, give the code a chance, it's only been public for a day! I
>>> haven't even got it to compile yet!
>>>
>>> I think it is a *vast* improvement over cubic, and possibly the first delay
>>> sensitive tcp that can compete effectively with it. I'm dying to test
>>> it thoroughly,
>>> but have a whole bunch other patches for wifi in my queue.
>>>
>>>> The authors suffer from typical naivete by thinking all flows are for file
>>>> transfer and that file transfer throughput is the right basic perspective,
>>>> rather than end to end latency/jitter due to sharing, and fair sharing
>>>> stability.
>>> While I agree *strongly* that lots of short flows is how the internet
>>> mostly operates, (I used to cite a paper on this a lot)
>>>
>>> a huge number of bulk flows exist that has been messing up the short
>>> flows. I think the number was something 70% of internet traffic has
>>> become netflix-like. *anything* e2e that can reduce the negative
>>> impact of the big fat flows on everything else is a win.
>>>
>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: "Jonathan Morton" <chromatix99@gmail.com>
>>>> Sent: Sat, Sep 17, 2016 at 4:11 pm
>>>> To: "Maciej Soltysiak" <maciej@soltysiak.com>
>>>> Cc: "Maciej Soltysiak" <maciej@soltysiak.com>,
>>>> "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
>>>> Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP
>>>> innet-next
>>>>
>>>>
>>>>> On 17 Sep, 2016, at 21:34, Maciej Soltysiak  wrote:
>>>>>
>>>>> Cake and fq_codel work on all packets and aim to signal packet loss early to
>>>>> network stacks by dropping; BBR works on TCP and aims to prevent packet loss.
>>>> By dropping, *or* by ECN marking.  The latter avoids packet loss.
>>>>
>>>>   - Jonathan Morton
>>>>
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>> --
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> http://blog.cerowrt.org
>>
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> http://blog.cerowrt.org
>>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel


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

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed]

On Wednesday, September 21, 2016 3:32am, "Alan Jenkins" <alan.christopher.jenkins@gmail.com> said:

> On 20/09/16 21:27, dpreed@reed.com wrote:
> I don't think the source is hard to identify.  It's Sandvine press
> releases.  That's what the periodic stories on Ars Technica are always
> derived from.
> 
> https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-traffic-is-now-streaming-video-and-audio.html

Press releases have almost no scientific verifiability and validity, and Sandvine is self-interested in a biased outcome. (Sad that Ars Technica just repeats these without questioning the numbers). In the past, I have actually questioned Sandvine directly, and had friends in the measurement community have asked for the raw data and methodology.  The response: "trade secrecy" and "customer privacy" prevent release of both raw data and methods.

If one is predisposed to "like" the result, one then repeats it as a "citation" often omitting the actual source and quoting the place where it appeared (e.g. Ars Technica said, rather than Sandvine said).

This is how propaganda works. It's exactly how propaganda works - I happen to have propaganda textbooks from the late 1940's that have chapters about these techniques.

Of course, the best propaganda is the stuff that you can get engineers in the field to promulgate based on their "gut feel".

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[Mikael Abrahamsson]

On Wed, 21 Sep 2016, dpreed@reed.com wrote:

> Of course, the best propaganda is the stuff that you can get engineers 
> in the field to promulgate based on their "gut feel".

Yes, I guess people who have been staring at traffic graphs and Netflow 
collector system output for 10-15 years have no insight into what and how 
much traffic is going where.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed]

On Wednesday, September 21, 2016 2:00pm, "Mikael Abrahamsson" <swmike@swm.pp.se> said:

> Yes, I guess people who have been staring at traffic graphs and Netflow
> collector system output for 10-15 years have no insight into what and how
> much traffic is going where.

That's exactly what I am saying.

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[Alan Jenkins]

On 20/09/2016, dpreed@reed.com <dpreed@reed.com> wrote:
> I constantly see the claim that >50% of transmitted data on the Internet are
> streaming TV. However, the source seems to be as hard to nail down as the
> original claim that >50% of Internet traffic was pirated music being sent
> over bittorrent.

uh, ibid.

50-60% "upstream bandwidth", 2010 and 2008 respectively.

I'm quite happy to believe the trend, at least. Do you have a
preferred assessment or even a rebuttal (back of the envelope,
whatever) for around that time?

BT for media is a real sweet spot.  Music particularly because people
_collect_, though I don't know what the timeline would look like for
music v.s. video.

Not as if the original figure was being cited as scientific gospel.

The last paper out of Netflix, they said it works best to stomp out
the isochronous behaviour and run in FTP mode as much as possible :).
(Subject to upper limits on quality and application buffers).  Even
dumb chunk downloading uses TCP; it's not isochronous in the way
that's usually used to describe RTP etc.

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

[dpreed]

Don't want to dwell on this, but Sandvine is not an unbiased source.  And it is apparently the *only* source - and 50% is a LOT.  Even Trump and Clinton don't have 50% of the electorate each. :-)

Does Sandvine have the resources to examine a true sample of all Internet traffic?

Maybe the NSA does.



On Wednesday, September 21, 2016 2:42pm, "Alan Jenkins" <alan.christopher.jenkins@gmail.com> said:

> On 20/09/2016, dpreed@reed.com <dpreed@reed.com> wrote:
>> I constantly see the claim that >50% of transmitted data on the Internet are
>> streaming TV. However, the source seems to be as hard to nail down as the
>> original claim that >50% of Internet traffic was pirated music being sent
>> over bittorrent.
> 
> uh, ibid.
> 
> 50-60% "upstream bandwidth", 2010 and 2008 respectively.
> 
> I'm quite happy to believe the trend, at least. Do you have a
> preferred assessment or even a rebuttal (back of the envelope,
> whatever) for around that time?
> 
> BT for media is a real sweet spot.  Music particularly because people
> _collect_, though I don't know what the timeline would look like for
> music v.s. video.
> 
> Not as if the original figure was being cited as scientific gospel.
> 
> The last paper out of Netflix, they said it works best to stomp out
> the isochronous behaviour and run in FTP mode as much as possible :).
> (Subject to upper limits on quality and application buffers).  Even
> dumb chunk downloading uses TCP; it's not isochronous in the way
> that's usually used to describe RTP etc.
>