Re: [Cerowrt-devel] [Bloat] [Cake] [Starlink] [Make-wifi-fast] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

[Matt Mathis via Cerowrt-devel]

--- Begin Message ---
I am very wary of a generalization of this problem: software engineers who
believe that they can code around arbitrary idosynchronies of network
hardware.  They often succeed, but generally at a severe performance
penalty.

How much do we know about the actual hardware?   As far as I understand the
math, some of the prime calculations used in Machine Learning are
isomorphic to multidimensional correlators and convolutions, which are
the same computations as needed to do phased array beam steering.   One can
imagine scenarios where Tesla (plans to) substantially overbuild the
computational HW by recycling some ML technology, and then beefing up the
SW over time as they better understand reality.

Also note that the problem really only needs to be solved in areas where
they will eventually have high density.   Most of the early deployment will
never have this problem.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
   however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of
control;
too weak risks being mistaken for tacit approval.


On Thu, Sep 2, 2021 at 10:36 AM David P. Reed  wrote:

> I just want to thank Dick Roy for backing up the arguments I've been
> making about physical RF communications for many years, and clarifying
> terminology here. I'm not the expert - Dick is an expert with real
> practical and theoretical experience - but what I've found over the years
> is that many who consider themselves "experts" say things that are actually
> nonsense about radio systems.
>
>
>
> It seems to me that Starlink is based on a propagation model that is quite
> simplistic, and probably far enough from correct that what seems "obvious"
> will turn out not to be true. That doesn't stop Musk and cronies from
> asserting these things as absolute truths (backed by actual professors,
> especially professors of Economics like Coase, but also CS professors,
> network protocol experts, etc. who aren't physicists or practicing RF
> engineers).
>
>
>
> The fact is that we don't really know how to build a scalable LEO system.
> Models can be useful, but a model can be a trap that causes even engineers
> to be cocky. Or as the saying goes, a Clear View doesn't mean a Short
> Distance.
>
>
>
> If there are 40 satellites serving 10,000 ground terminals simultaneously,
> exactly what is the propagation environment like? I can tell you one thing:
> if the phased array is digitized at some sample rate and some equalization
> and some quantization, the propagation REALLY matters in serving those
> 10,000 ground terminals scattered randomly on terrain that is not optically
> flat and not fully absorbent.
>
>
>
> So how will Starlink scale? I think we literally don't know. And the
> modeling matters.
>
>
>
> Recently a real propagation expert (Ted Rapaport and his students) did a
> study of how well 70 GHz RF signals propagate in an urban environment -
> Brooklyn.  The standard model would say that coverage would be terrible!
> Why? Because supposedly 70 GHz is like visible light - line of sight is
> required or nothing works.
>
>
>
> But in fact, Ted, whom I've known from being on the FCC Technological
> Advisory Committee (TAC) together when it was actually populated with
> engineers and scientists, not lobbyists, discovered that scattering and
> diffraction at 70 GHz in an urban environment significantly expands
> coverage of a single transmitter. Remarkably so. Enough that "cellular
> architecture" doesn't make sense in that propagation environment.
>
>
>
> So all the professional experts are starting from the wrong place, and
> amateurs perhaps even more so.
>
>
>
> I hope Starlink views itself as a "research project". I'm afraid it
> doesn't - partly driven by Musk, but equally driven by the FCC itself,
> which demands that before a system is deployed that the entire plan be
> shown to work (which would require a "model" that is actually unknowable
> because something like this has never been tried). This is a problem with
> today's regulation of spectrum - experiments are barred, both by law, and
> by competitors who can claim your system will destroy theirs and not work.
>
>
>
> But it is also a problem when "fans" start setting expectations way too
> high. Like claiming that Starlink will eliminate any need for fiber. We
> don't know that at all!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tuesday, August 10, 2021 2:11pm, "Dick Roy" 
> said:
>
> To add a bit more, as is easily seen below, the amplitudes of each of the
> transfer functions between the three transmit and three receive antennas
> are extremely similar.  This is to be expected, of course, since the
> “aperture” of each array is very small compared to the distance between
> them.  What is much more interesting and revealing is the relative phases.
> Obviously this requires coherent receivers, and 

Re: [Cerowrt-devel] Abandoning Window-based CC Considered Harmful (was Re: [Bloat] Bechtolschiem)

[Matt Mathis via Cerowrt-devel]

--- Begin Message ---
I think there is something missing from your model.I just scanned your
paper and noticed that you made no mention of rounding errors, nor some
details around the drain phase timing,   The implementation guarantees that
the actual average rate across the combined BW probe and drain is strictly
less than the measured maxBW and that the flight size comes back down to
minRTT*maxBW before returning to unity pacing gain.  In some sense these
checks are redundant, but If you don't do them, it is absolutely true that
you are at risk of seeing divergent behaviors.

That said, it is also true that multi-stream BBR behavior is quite
complicated and needs more queue space than single stream.   This
complicates the story around the traditional workaround of using multiple
streams to compensate for Reno & CUBIC lameness at larger scales (ordinary
scales today).Multi-stream does not help BBR throughput and raises the
queue occupancy, to the detriment of other users.

And yes, in my presentation, I described the core BBR algorithms as a
framework, which might be extended to incorporate many additional
algorithms if they provide optimal control in some settings.  And yes,
several are present in BBRv2.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
   however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of
control;
too weak risks being mistaken for tacit approval.


On Thu, Jul 8, 2021 at 4:24 AM Bless, Roland (TM) 
wrote:

> Hi Matt,
>
> On 08.07.21 at 00:38 Matt Mathis wrote:
>
> Actually BBR does have a window based backup, which normally only comes
> into play during load spikes and at very short RTTs.   It defaults to
> 2*minRTT*maxBW, which is twice the steady state window in it's normal paced
> mode.
>
> So yes, BBR follows option b), but I guess that you are referring to BBRv1
> here.
> We have shown in [1, Sec.III] that BBRv1 flows will *always* run
> (conceptually) toward their above quoted inflight-cap of
> 2*minRTT*maxBW, if more than one BBR flow is present at the bottleneck. So
> strictly speaking " which *normally only* comes
> into play during load spikes and at very short RTTs" isn't true for
> multiple BBRv1 flows.
>
> It seems that in BBRv2 there are many more mechanisms present
> that try to control the amount of inflight data more tightly and the new
> "cap"
> is at 1.25 BDP.
>
> This is too large for short queue routers in the Internet core, but it
> helps a lot with cross traffic on large queue edge routers.
>
> Best regards,
>  Roland
>
> [1] https://ieeexplore.ieee.org/document/8117540
>
>
> On Wed, Jul 7, 2021 at 3:19 PM Bless, Roland (TM) 
> wrote:
>
>> Hi Matt,
>>
>> [sorry for the late reply, overlooked this one]
>>
>> please, see comments inline.
>>
>> On 02.07.21 at 21:46 Matt Mathis via Bloat wrote:
>>
>> The argument is absolutely correct for Reno, CUBIC and all
>> other self-clocked protocols.  One of the core assumptions in Jacobson88,
>> was that the clock for the entire system comes from packets draining
>> through the bottleneck queue.  In this world, the clock is intrinsically
>> brittle if the buffers are too small.  The drain time needs to be a
>> substantial fraction of the RTT.
>>
>> I'd like to separate the functions here a bit:
>>
>> 1) "automatic pacing" by ACK clocking
>>
>> 2) congestion-window-based operation
>>
>> I agree that the automatic pacing generated by the ACK clock (function 1)
>> is increasingly
>> distorted these days and may consequently cause micro bursts.
>> This can be mitigated by using paced sending, which I consider very
>> useful.
>> However, I consider abandoning the (congestion) window-based approaches
>> with ACK feedback (function 2) as harmful:
>> a congestion window has an automatic self-stabilizing property since the
>> ACK feedback reflects
>> also the queuing delay and the congestion window limits the amount of
>> inflight data.
>> In contrast, rate-based senders risk instability: two senders in an M/D/1
>> setting, each sender sending with 50%
>> bottleneck rate in average, both using paced sending at 120% of the
>> average rate, suffice to cause
>> instability (queue grows unlimited).
>>
>> IMHO, two approaches seem to be useful:
>> a) congestion-window-based operation with paced sending
>> b) rate-based/paced sending with limiting the amount of inflight data
>>
>>
>> However, we have reached the point where we need to discard that
>> requirement.  One of th

Re: [Cerowrt-devel] Abandoning Window-based CC Considered Harmful (was Re: [Bloat] Bechtolschiem)

[Matt Mathis via Cerowrt-devel]

--- Begin Message ---
Actually BBR does have a window based backup, which normally only comes
into play during load spikes and at very short RTTs.   It defaults to
2*minRTT*maxBW, which is twice the steady state window in it's normal paced
mode.

This is too large for short queue routers in the Internet core, but it
helps a lot with cross traffic on large queue edge routers.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
   however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of
control;
too weak risks being mistaken for tacit approval.


On Wed, Jul 7, 2021 at 3:19 PM Bless, Roland (TM) 
wrote:

> Hi Matt,
>
> [sorry for the late reply, overlooked this one]
>
> please, see comments inline.
>
> On 02.07.21 at 21:46 Matt Mathis via Bloat wrote:
>
> The argument is absolutely correct for Reno, CUBIC and all
> other self-clocked protocols.  One of the core assumptions in Jacobson88,
> was that the clock for the entire system comes from packets draining
> through the bottleneck queue.  In this world, the clock is intrinsically
> brittle if the buffers are too small.  The drain time needs to be a
> substantial fraction of the RTT.
>
> I'd like to separate the functions here a bit:
>
> 1) "automatic pacing" by ACK clocking
>
> 2) congestion-window-based operation
>
> I agree that the automatic pacing generated by the ACK clock (function 1)
> is increasingly
> distorted these days and may consequently cause micro bursts.
> This can be mitigated by using paced sending, which I consider very
> useful.
> However, I consider abandoning the (congestion) window-based approaches
> with ACK feedback (function 2) as harmful:
> a congestion window has an automatic self-stabilizing property since the
> ACK feedback reflects
> also the queuing delay and the congestion window limits the amount of
> inflight data.
> In contrast, rate-based senders risk instability: two senders in an M/D/1
> setting, each sender sending with 50%
> bottleneck rate in average, both using paced sending at 120% of the
> average rate, suffice to cause
> instability (queue grows unlimited).
>
> IMHO, two approaches seem to be useful:
> a) congestion-window-based operation with paced sending
> b) rate-based/paced sending with limiting the amount of inflight data
>
>
> However, we have reached the point where we need to discard that
> requirement.  One of the side points of BBR is that in many environments it
> is cheaper to burn serving CPU to pace into short queue networks than it is
> to "right size" the network queues.
>
> The fundamental problem with the old way is that in some contexts the
> buffer memory has to beat Moore's law, because to maintain constant drain
> time the memory size and BW both have to scale with the link (laser) BW.
>
> See the slides I gave at the Stanford Buffer Sizing workshop december
> 2019: Buffer Sizing: Position Paper
> <https://docs.google.com/presentation/d/1VyBlYQJqWvPuGnQpxW4S46asHMmiA-OeMbewxo_r3Cc/edit#slide=id.g791555f04c_0_5>
>
>
> Thanks for the pointer. I don't quite get the point that the buffer must
> have a certain size to keep the ACK clock stable:
> in case of an non application-limited sender, a very small buffer suffices
> to let the ACK clock
> run steady. The large buffers were mainly required for loss-based CCs to
> let the standing queue
> build up that keeps the bottleneck busy during CWnd reduction after packet
> loss, thereby
> keeping the (bottleneck link) utilization high.
>
> Regards,
>
>  Roland
>
>
> Note that we are talking about DC and Internet core.  At the edge, BW is
> low enough where memory is relatively cheap.   In some sense BB came about
> because memory is too cheap in these environments.
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> We must not tolerate intolerance;
>however our response must be carefully measured:
> too strong would be hypocritical and risks spiraling out of
> control;
> too weak risks being mistaken for tacit approval.
>
>
> On Fri, Jul 2, 2021 at 9:59 AM Stephen Hemminger <
> step...@networkplumber.org> wrote:
>
>> On Fri, 2 Jul 2021 09:42:24 -0700
>> Dave Taht  wrote:
>>
>> > "Debunking Bechtolsheim credibly would get a lot of attention to the
>> > bufferbloat cause, I suspect." - dpreed
>> >
>> > "Why Big Data Needs Big Buffer Switches" -
>> >
>> http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf
>> >
>&

Re: [Cerowrt-devel] [Bloat] Bechtolschiem

[Matt Mathis via Cerowrt-devel]

--- Begin Message ---
The argument is absolutely correct for Reno, CUBIC and all
other self-clocked protocols.  One of the core assumptions in Jacobson88,
was that the clock for the entire system comes from packets draining
through the bottleneck queue.  In this world, the clock is intrinsically
brittle if the buffers are too small.  The drain time needs to be a
substantial fraction of the RTT.

However, we have reached the point where we need to discard that
requirement.  One of the side points of BBR is that in many environments it
is cheaper to burn serving CPU to pace into short queue networks than it is
to "right size" the network queues.

The fundamental problem with the old way is that in some contexts the
buffer memory has to beat Moore's law, because to maintain constant drain
time the memory size and BW both have to scale with the link (laser) BW.

See the slides I gave at the Stanford Buffer Sizing workshop december
2019: Buffer
Sizing: Position Paper



Note that we are talking about DC and Internet core.  At the edge, BW is
low enough where memory is relatively cheap.   In some sense BB came about
because memory is too cheap in these environments.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
   however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of
control;
too weak risks being mistaken for tacit approval.


On Fri, Jul 2, 2021 at 9:59 AM Stephen Hemminger 
wrote:

> On Fri, 2 Jul 2021 09:42:24 -0700
> Dave Taht  wrote:
>
> > "Debunking Bechtolsheim credibly would get a lot of attention to the
> > bufferbloat cause, I suspect." - dpreed
> >
> > "Why Big Data Needs Big Buffer Switches" -
> >
> http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf
> >
>
> Also, a lot depends on the TCP congestion control algorithm being used.
> They are using NewReno which only researchers use in real life.
>
> Even TCP Cubic has gone through several revisions. In my experience, the
> NS-2 models don't correlate well to real world behavior.
>
> In real world tests, TCP Cubic will consume any buffer it sees at a
> congested link. Maybe that is what they mean by capture effect.
>
> There is also a weird oscillation effect with multiple streams, where one
> flow will take the buffer, then see a packet loss and back off, the
> other flow will take over the buffer until it sees loss.
>
> ___
> Bloat mailing list
> bl...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
--- End Message ---
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] access to cmsg from go?

[Matt Mathis via Cerowrt-devel]

--- Begin Message ---
Is there running code in C?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
   however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out of
control;
too weak risks being mistaken for tacit approval.


On Sat, Jun 19, 2021 at 2:59 PM Dave Taht  wrote:

> anyone have any good ideas here? https://github.com/golang/go/issues/46831
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
>
> Dave Täht CTO, TekLibre, LLC
> ___
> Cake mailing list
> c...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
--- End Message ---
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] Bad news site - fashionsnowboots

[Matt Mathis]

https://www.google.com/webmasters/tools/spamreportform


Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Wed, Apr 22, 2015 at 7:03 AM, Simon Barber si...@superduper.net wrote:

 DMCA takedown request?

 Sent with AquaMail for Android
 http://www.aqua-mail.com



 On April 22, 2015 4:42:38 AM Rich Brown richb.hano...@gmail.com wrote:

  Google Alerts informed me that site bufferbloat dot fashionsnowboots dot
 com is talking about Bufferbloat. Sure enough, it appears to have cloned
 the content from our home page with the following additions:

 - It offers to install the Java plugin 12.3
 - All the links on the page encourage you to install Java
 - One link automatically downloaded a Flash Updater - helpfully a .dmg
 for my Mac.

 My first reaction:

 1) Only visit the site with your best armored browser
 2) Please don't post their URL in messages - they don't need additional
 SEO juice
 3) Any idea what else we can do about this?

 Rich

 PS whois fashionsnowboots.com shows:

 Domain Name: FASHIONSNOWBOOTS.COM
 Registry Domain ID: 1864266509_DOMAIN_COM-VRSN
 Registrar WHOIS Server: whois.networksolutions.com
 Registrar URL: http://networksolutions.com
 Updated Date: 2015-01-29T02:04:19Z
 Creation Date: 2014-06-25T18:13:23Z
 Registrar Registration Expiration Date: 2015-06-25T04:00:00Z
 Registrar: NETWORK SOLUTIONS, LLC.
 Registrar IANA ID: 2
 Registrar Abuse Contact Email: ab...@web.com
 Registrar Abuse Contact Phone: +1.8003337680
 Reseller:
 Domain Status:
 Registry Registrant ID:
 Registrant Name: Rosser, Adam
 Registrant Organization: 0
 Registrant Street: 3499 August Lane
 Registrant City: Alexandria
 Registrant State/Province: LA
 Registrant Postal Code: 71301
 Registrant Country: US
 Registrant Phone: 318-419-4502
 Registrant Phone Ext:
 Registrant Fax:
 Registrant Fax Ext:
 Registrant Email: bedazzledgame@out1ook.com
 Registry Admin ID:
 Admin Name: Rosser, Adam
 Admin Organization: 0
 Admin Street: 3499 August Lane
 Admin City: Alexandria
 Admin State/Province: LA
 Admin Postal Code: 71301
 Admin Country: US
 Admin Phone: 318-419-4502
 Admin Phone Ext:
 Admin Fax:
 Admin Fax Ext:
 Admin Email: bedazzledgame@out1ook.com
 Registry Tech ID:
 Tech Name: Rosser, Adam
 Tech Organization: 0
 Tech Street: 3499 August Lane
 Tech City: Alexandria
 Tech State/Province: LA
 Tech Postal Code: 71301
 Tech Country: US
 Tech Phone: 318-419-4502
 Tech Phone Ext:
 Tech Fax:
 Tech Fax Ext:
 Tech Email: bedazzledgame@out1ook.com
 Name Server: PNS1.CLOUDNS.NET
 Name Server: PNS2.CLOUDNS.NET
 Name Server: PNS3.CLOUDNS.NET
 Name Server: PNS4.CLOUDNS.NET
 Name Server: PNS5.CLOUDNS.NET
 Name Server: PNS6.CLOUDNS.NET
 DNSSEC: Unsigned
 URL of the ICANN WHOIS Data Problem Reporting System:
 http://wdprs.internic.net/
  Last update of whois database: Wed, 22 Apr 2015 11:37:31 GMT v
 ___
 Bloat mailing list
 bl...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/bloat



 ___
 Bloat mailing list
 bl...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/bloat

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

Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Matt Mathis]

Two of the tests in my model based metrics draft (for IPPM) are for
AQM (like) tests.   One we have pretty good theory for (preventing
standing queues in congestion avoidance) and the other we don't
(exiting from slowstart at a reasonable window).

See: draft-mathis-ippm-model-based-metrics-01.txt

My intent is that these tests will become part of a future IPPM
standard on what a network must do in order to support modern
applications at specific performance levels. Although the draft
will not specify AQM algorithms at all, it will forbid some non-AQM
behaviors such as unreasonable standing queues.   To the extent that
it gets traction as a standard, it will strongly encourage deployment,
even if we are not totally convinced that our current AQM algorithms
are 100% correct.

However, It is not clear that we need to standardize AQM - It strikes
me as one area where we can permit pretty much unfettered diversity in
the operational Internet as long as it meets a pretty low  it seems
to work bar.

For this reason it is important to deploy your favorite algorithm(s)
ASAP, because they are all infinitely better than none, and future
improvements will be relatively minor by comparison.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.


On Thu, Feb 28, 2013 at 10:47 AM, dpr...@reed.com wrote:

 A small suggestion.  Instead of working on *algorithms*, focus on getting 
 something actually *deployed* to fix the very real issues that we have today 
 (preserving the option to upgrade later if need be).



 The folks who built the Internet (I was there, as you probably know) focused 
 on making stuff that worked and interoperated, not publishing papers or RFCs.



 -Original Message-
 From: Wesley Eddy w...@mti-systems.com
 Sent: Thursday, February 28, 2013 1:11pm
 To: Dave Taht dave.t...@gmail.com
 Cc: bloat-annou...@lists.bufferbloat.net, Martin Stiemerling 
 martin.stiemerl...@neclab.eu, cerowrt-devel@lists.bufferbloat.net, bloat 
 bl...@lists.bufferbloat.net
 Subject: Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the 
 ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

 On 2/28/2013 10:53 AM, Dave Taht wrote:
 
  For those that don't attend ietf meetings in person, there is usually
  live audio and jabber chat hooked up into the presentations.
 
  See y'all there, next month, in one form or another.
 


 In the TSVAREA meeting, we've also set aside some time to talk
 about AQM and whether there's interest and energy to do some
 more specific work on AQM algs in the IETF (e.g. like CoDel and
 PIE):

 https://datatracker.ietf.org/meeting/86/agenda/tsvarea

 I'm working with Martin on some slides to seed the discussion,
 but we hope that it's mostly the community that we hear from,
 following up in the higher-bandwidth face-to-face time from
 the thread we had on the tsv-a...@ietf.org mailing list a few
 months ago.


 --
 Wes Eddy
 MTI Systems
 ___
 Cerowrt-devel mailing list
 Cerowrt-devel@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/cerowrt-devel


 ___
 Bloat mailing list
 bl...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/bloat

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