From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BC0BE3CB35 for ; Mon, 10 Aug 2020 15:13:48 -0400 (EDT) Received: by mail-ej1-x62e.google.com with SMTP id qc22so10518594ejb.4 for ; Mon, 10 Aug 2020 12:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uner-edu-ar.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gIm582J/Nlyt1nx/Fm5C+42ruqggOUlb0ZlwYaDoEWM=; b=k9ZkiPvDkWOr0zTA+6gsd2enV/egmWuDuxPoJU0iMSxbaJXJU5rC/nWulBzaFLjTP6 umlJDJEkkRxkxccSEtFRzGltw5NL5tCBhRLH0QAgw3Ah+llH3cRNh90uHpE/5EjH+YJ/ jtdGxbuv9j0s4atSsWQvWGI+gp5HYGgR6Fwh9a0UYGVfatRfRHhEUgJ7UQaMwSW6iAE1 A+cU6Ii62X+HURxYsHcim3N3Chp99sRMiUoa3ZWrHfHdM0DraRK/le2GrNMtGVLeZjTa iH62d1z4vkFg0J13vFsIZRnh1VKABTzxY5RubuFH/BrzZ9rT7b+PW9U6ttQzJzLKDAZj uvnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gIm582J/Nlyt1nx/Fm5C+42ruqggOUlb0ZlwYaDoEWM=; b=pJ0RF5JbswW+1i0BEreXN9KN4x3Q9hfjU3d8Wm6WFcwfjIT8i8iCOi7DBpl/9TleLn Ev1LAlRbCBlUIsU0EoBY3xkpEDyi/FgRUikCR5UjGDvkkKlH4mqxnJHwNEVAA7nS/DMR VtHmrnVwbwF+jLrqxez70xXv6YdpYQUkKd4h/UJyUdlBw6ZicZWrJZxAnc26QByT5Xqw Y+u2V9UV/eQzMprzxeo+XRcWHrQL5Ps7ILkeLg8dSa0hUY687VMMQra+y6/8Gu6ZJoDp 9qtXS5Iy6Ez3IHzf2CYbhKcVj2S4lO3Qd6ah1SWH7d0RbITOLjX3lBkh9QLH8h6kn/Ur VeRQ== X-Gm-Message-State: AOAM533VBmp6+QTctIBI96omajhUzicTV9iJLTTNGAzP4c9v2Mg0+MtY pvbzPiy9BjjDj0Jec5kfYvyEHw/y8WuVcwkROVY5dXP8egE= X-Google-Smtp-Source: ABdhPJyX+/3rN4AU32xbqPql+d7UWS/At3LwMhUO4Zkb6ZhnWjBrGEDYrWjJBoKdIcd6AVJPH+RFKId0z4rHRjZ694o= X-Received: by 2002:a17:906:1756:: with SMTP id d22mr22956491eje.29.1597086827462; Mon, 10 Aug 2020 12:13:47 -0700 (PDT) MIME-Version: 1.0 References: <225a9c89-ac76-f21e-1450-5deeb3cd23eb@tomh.org> <04949cee-c4de-900c-e1b1-4b1f227933eb@rogers.com> <95BA0E2B-9DB3-433F-804F-118AC7A90F5E@jonathanfoulkes.com> In-Reply-To: <95BA0E2B-9DB3-433F-804F-118AC7A90F5E@jonathanfoulkes.com> From: "Carlos R. Pasqualini" Date: Mon, 10 Aug 2020 16:13:36 -0300 Message-ID: To: Y via Bloat Content-Type: multipart/alternative; boundary="00000000000006daf405ac8ac1dc" X-Mailman-Approved-At: Tue, 11 Aug 2020 07:39:55 -0400 Subject: Re: [Bloat] How about a topical LWN article on demonstrating the real-world goodness of CAKE? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:13:49 -0000 --00000000000006daf405ac8ac1dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great topic, indeed! We (almost?) all know that we can put a linux box between our network and the Internet and apply cake on the WAN interface (may be an ingress too) and most of the bufferbloat problems disappear One thing I suggest is to bring more cake awareness in other communities and commercial products to support it. As an example, a was unable to find a way to get cake on pfSense/opnSense (may be FreeBSD doesn't support cake?) only something similar to fq_codel. In worst shape, are products like Mikrotik, used by quite a few "network professionals" and some ISPs, where I was unable to find any way to get ride of bufferbloat Thanks! El lun., 10 ago. 2020 a las 14:58, Jonathan Foulkes () escribi=C3=B3: > Hi David, > > Great topic, and glad you brought it up, as increasing awareness of all > the goodness that de-bloating brings to end users is important, especiall= y > with all the WFH and soon, teaching/learning going on these days. > > Background / disclosure: I=E2=80=99m the founder and CEO of Evenroute, so= first, > thank you for your order :-) Second, please let me know if you have any > questions once you get the unit. Happy to personally support you, or any > member of this list. > > Given I have access to the combined data of the deployed IQrouter fleet, = I > have a pretty good view of how well Cake performs in the real world, as w= e > are on nearly every ISP domestically (US) and a surprising number of > International deployments as well (even though we only market in the US). > as you might imagine, given our marketing, we have a huge number of users > with really bad lines, or on challenging tech, like WISPs & Satellite. So > we get to see the worst of the worst. > But interestingly enough, we also have a certain amount of users with > extremely low and stable latencies with no QoS, yet they still continue t= o > deploy their IQrouters, likely because the prior ISP-supplied device > *added* latencies, and the benefits of fairness in the per-device, per-ho= st > settings in Cake, plus correctly prioritizing based on type & DSCP marks > (most WiFi-calling smartphone traffic is correctly marked). > > Are the risks and tradeoffs well enough understood (and visible enough > for troubleshooting) to recommend broader deployment? > > We=E2=80=99ve been deploying SQM / CAKE for 4+ years in the IQrouter, and= while we > have evolved a lot of our algorithms do deal with the millions of > permutations in configurations and settings, I=E2=80=99ve seen SQM and la= tely CAKE > likewise mature, and my assessment is they are indeed ready for prime tim= e > in terms of foundational tech. > The challenge is not the core tech, it=E2=80=99s accessibility. That was = my take > in 2015 when I first discovered it, and led to the founding of my company= . > > As for troubleshooting visibility, check out the Status->Ping Stats page > once your IQrouter has been running for a few days. Very helpful in > triaging modem and line issues. Basically its a line capacity usage monit= or > and ping plotter. > > but in my view we haven't converted "grandma". > > > Because until I produced a product with zero user configuration > requirements (relative to QoS), =E2=80=98grandma=E2=80=99 was never a via= ble user. > Back story: I live in a large (3,000 homes) development in a rural area, > most residents are retired professionals and DSL was the only choice up > until recently, so a bunch of non-technical grandma's and grandpas are my > neighbors. The IQrouter was developed to meet the needs of that audience. > Grandma should be able to deploy in 15 minutes and have a de-bloated DSL > connection that got rid of the 5,000ms+ lag spikes. So initial config > workflow, and all the tuning and dynamic line adaptation were largely bor= n > of dealing with my local needs. > > Funny enough, our focus on non-techie usability led to a skeptical > backlash from some =E2=80=99techies=E2=80=99, who find our marketing mess= aging and simple > UI too off-putting for them. Even though we do expose the full native UI > for OpenWRT under the =E2=80=98Advanced Menus=E2=80=99 option. Heck, you = can even instal > OpenWRT packages on this thing. > Smart techies love though, a recent IT guy wrote in response to our > support team letting him know about OpenWRT support was: "Now, I know > that this really is the *best router* for all consumers to use in their > homes!=E2=80=9D. We made his WISP service usable. > > Because of the degree to which we're working from home and > videoconferencing, a lot of low-price, medium-performance devices are > suddenly too wimpy for their new role. > > Big time. As noted above, it not just the CPE devices, it=E2=80=99s the c= ongestion > on the backhauls that causes issues, and it=E2=80=99s everything from DSL= (slammed > DSLAMs are endemic) to cable systems with oversubscribed local loops and > congested CMTS backhaul. Hell, even fiber to the home ISPs manage to have > variable capacity (and bloat) in the evenings. > Traffic management is a requirement these days. > > I propose we show the results in terms that we can explain to Grandma, > specifically concentrating on functioning VOIP. > > > This is desperately needed, as there need to be more points of proof and > articles outlining the problem, and the impacts of resolving it with > effective traffic management. > > Stuff like this article from Jim Gettys on the needs of teachers. BTW- he > calls out the IQrouter as his =E2=80=98Go to=E2=80=99 recommendation for = non-techies. He > runs one himself and gave one to his non-techie brother. Bufferbloat in > Action due to Covid-19 > > > More comments on other response later, got work to do ;-) > > Cheers, > > Jonathan Foulkes > > > On Aug 10, 2020, at 8:57 AM, David Collier-Brown > wrote: > > On 2020-08-09 5:35 p.m., Jonathan Morton wrote: > > Are the risks and tradeoffs well enough understood (and visible enough > for troubleshooting) to recommend broader deployment? > > I recently gave openwrt a try on some hardware that I ultimately > concluded was insufficient for the job. Fairly soon after changing out > my access point, I started getting complaints of Wi-Fi dropping in my > household, especially when someone was trying to videoconference. I > discovered that my AP was spontaneously rebooting, and the box was > getting hot. > > Most CPE devices these days rely on hardware accelerated packet forwardin= g to achieve their published specs. That's all about taking packets in one= side and pushing them out the other as quickly as possible, with only mini= mal support from the CPU (likely, new connections get a NAT/firewall lookup= , that's all). It has the advantages of speed and power efficiency, but un= fortunately it is also incompatible with our debloating efforts. So debloa= ted CPE will tend to run hotter and with lower peak throughput, which may b= e noticeable to cable and fibre users; VDSL (FTTC) users might have service= of 80Mbps or less where this effect is less likely to matter. > > It sounds like that AP had a very marginal thermal design which caused th= e hardware to overheat as soon as the CPU was under significant load, which= it can easily be when a shaper and AQM are running on it at high throughpu= t. The cure is to use better designed hardware, though you could also cont= emplate breaking the case open to cure the thermal problem directly. There= are some known reliable models which could be collected into a list. As a= rule of thumb, the ones based on ARM cores are likely to be designed with = CPU performance more in mind than those with MIPS. > > Cake has some features which can be used to support explicit classificati= on and (de)prioritisation of traffic via firewall marking rules, either by = rewriting the Diffserv field or by associating metadata with packets within= the network stack (fwmark). This can be very useful for pushing Bittorren= t or WinUpdate swarm traffic out of the way. But for most situations, the = default flow-isolating behaviour already works pretty well, especially for = ensuring that one computer's network load has only a bounded effect on any = other. We can discuss that in more detail if that would be helpful. > > I'm primarily thinking of *this week's* version of the home router > problem (;-)) > > Because of the degree to which we're working from home and > videoconferencing, a lot of low-price, medium-performance devices are > suddenly too wimpy for their new role. > > A (very!) draft version is up in Google docs, at > https://docs.google.com/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BU= K0Ju9w/edit?usp=3Dsharing > > Using myself as the guinea-pig, running pfifo-fast was clearly bad, > fq_codel was better, and cake was good with a newish Fedora and the stock > Rogers router. It's been a while since I did rrul tests, and in any case= , > I think that to convince readers we need a very practical way of making i= t > clear that they have a problem. I'm thinking that making VOIP fail might = do > the trick (;-)) > > The hard part, IMHO, is constructing a test that immediately communicates > the idea that the reader has a problem, and that CAKE addresses it. > > Returning to the hardware question, https://evenroute.com/iqrv3 seems to > be capable of handling up to ~300 Mbit/S connections, and my ISP only > delivers 170 (and advertises 150, which is mildly surprising!) > > I just ordered one, so I'll have a 'plug in" example, along with > reflashing my linksys for the umpty-thousandth time. > > --dave > > I suspect not enough people are aware of the later efforts of the > bufferbloat team, so I'm thinking of one or two articles, starting with L= WN > and an audience of aficionados. > > The core community is aware of what we've done, but in my view we haven't > converted "grandma". Grandma, as well as a whole bunch of ordinary > engineers and partners of engineers, are dependent on debloated performan= ce > because they're working at home now, and competing with granddaughter > playing video games while they're trying to hold a video call. > > Right now, my colleagues at work suffer from more than a second of > bloat-related lag. They therefore tend to speak over each other on > con-calls, apologize, start again and talk over each other, again. After = a > little while, the picture becomes a distinctly silly one: a bunch of grow= n > adults putting their hands up and waving, like little kids in school. > No-one has called out =E2=80=9Cme, me, teacher=E2=80=9D yet, but I expect= it any time. > > I propose we show the results in terms that we can explain to Grandma, > specifically concentrating on functioning VOIP. I just upgraded to Fedora > 31, and the networking is absolutely stock, so I make a perfect > victim/guinea-pig (;-)) > > Who's interested? > > > > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the restdavecb@sp= amcop.net | -- Mark Twain > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 Carlos Pasqualini +5493454040137 Administraci=C3=B3n de Redes --00000000000006daf405ac8ac1dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great topic, indeed!


We = (almost?) all know that we can put a linux box between our network and the = Internet and apply cake on the WAN interface (may be an ingress too) and mo= st of the bufferbloat problems disappear
=C2=A0=C2=A0
O= ne thing I suggest is to bring more cake awareness in other communities and= commercial products to support it.

As an example,= a was unable to find a way to get cake on pfSense/opnSense (may be FreeBSD= doesn't support cake?) only something similar to fq_codel.
<= br>
In worst shape, are products like Mikrotik, used by quite a f= ew "network professionals" and some ISPs, where I was unable to f= ind any way to get ride=C2=A0of=C2=A0bufferbloat

<= br>

Thanks!


El lun., 10 ago. 2= 020 a las 14:58, Jonathan Foulkes (<jf@jonathanfoulkes.com>) escribi=C3=B3:
Hi David,=C2=A0

Great topic, and glad you brought it= up, as increasing awareness of all the goodness that de-bloating brings to= end users is important, especially with all the WFH and soon, teaching/lea= rning going on these days.

Background / disclosure= : I=E2=80=99m the founder and CEO of Evenroute, so first, thank you for you= r order :-) =C2=A0Second, please let me know if you have any questions once= you get the unit. Happy to personally support you, or any member of this l= ist.

Given I have access to the combined data of t= he deployed IQrouter fleet, I have a pretty good view of how well Cake perf= orms in the real world, as we are on nearly every ISP domestically (US) and= a surprising number of International deployments as well (even though we o= nly market in the US).
as you might imagine, given our marketing,= we have a huge number of users with really bad lines, or on challenging te= ch, like WISPs & Satellite. So we get to see the worst of the worst.
But interestingly enough, we also have a certain amount of users wi= th extremely low and stable latencies with no QoS, yet they still continue = to deploy their IQrouters, likely because the prior ISP-supplied device *ad= ded* latencies, and the benefits of fairness in the per-device, per-host se= ttings in Cake, plus correctly prioritizing based on type & DSCP marks = (most WiFi-calling smartphone traffic is correctly marked).
Are the risks and tradeoffs well enough understood (and visible eno=
ugh=20
for troubleshooting) to recommend broader deployment?
We=E2=80=99ve been deploying SQM / CAKE f= or 4+ years in the IQrouter, and while we have evolved a lot of our algorit= hms do deal with the=C2=A0millions=C2=A0of permutat= ions in configurations and settings, I=E2=80=99ve seen SQM and lately CAKE = likewise mature, and my=C2=A0assessment=C2=A0is they are indeed ready for p= rime time in terms of foundational tech.
The challenge is not the core tech, it=E2=80=99s=C2=A0accessib= ility. That was my take in 2015 when I first discovered it, and led to the = founding of my company.

As for troubleshoot= ing visibility, check out the Status->Ping Stats page once your IQrouter= has been running for a few days. Very helpful in triaging modem and line i= ssues. Basically its a line capacity usage monitor and ping plotter.
<= div>
but in my view we haven't = converted "grandma".

Because unti= l I produced a product with zero user configuration requirements (relative = to QoS), =E2=80=98grandma=E2=80=99 was never a viable user.
Back = story: I live in a large (3,000 homes) development in a rural area, most re= sidents are retired professionals and DSL was the only choice up until rece= ntly, so a bunch of non-technical grandma's and grandpas are my neighbo= rs. The IQrouter was developed to meet the needs of that audience. Grandma = should be able to deploy in 15 minutes and have a de-bloated DSL connection= that got rid of the 5,000ms+ lag spikes. So initial config workflow, and a= ll the tuning and dynamic line adaptation were largely born of dealing with= my local needs.

Funny enough, our focus on non-te= chie usability led to a skeptical backlash from some =E2=80=99techies=E2=80= =99, who find our marketing messaging and simple UI too off-putting for the= m. Even though we do expose the full native UI for OpenWRT under the =E2=80= =98Advanced Menus=E2=80=99 option. Heck, you can even instal OpenWRT packag= es on this thing.
Smart techies love though, a recent IT guy wrot= e in response to our support team letting him know about OpenWRT support wa= s: "Now, I know that = this really is the=C2=A0best router= =C2=A0for all consumers to use in their homes!=E2=80=9D. We made his WISP serv= ice usable.

Beca= use of the degree to which we're working from home and videoconferencin= g, a lot of low-price, medium-performance devices are suddenly too wimpy fo= r their new role.

Big time. As noted abo= ve, it not just the CPE devices, it=E2=80=99s the congestion on the backhau= ls that causes issues, and it=E2=80=99s everything from DSL (slammed DSLAMs= are endemic) to cable systems with oversubscribed local loops and congeste= d CMTS backhaul. Hell, even fiber to the home ISPs manage to have variable = capacity (and bloat) in the evenings.

Traffic management is a requi= rement these days.

=
I propose we show the results in terms that we ca= n explain to Grandma, specifically concentrating on functioning VOIP.

This is desperately needed, as the= re need to be more points of proof and articles outlining the problem, and = the impacts of resolving it with effective traffic management.
Stuff like this article from Jim Gettys on the needs of teache= rs. BTW- he calls out the IQrouter as his =E2=80=98Go to=E2=80=99 recommend= ation for non-techies. He runs one himself and gave one to his non-techie b= rother.=C2=A0Bufferbloat in Action due to= =C2=A0Covid-19

More comments on other response= later, got work to do ;-)

Cheers,

<= /div>
Jonathan Foulkes


<= /div>
On Aug 10, 2020, at 8:57 AM, David= Collier-Brown <davecb.42@gmail.com> wrote:

=20 =20 =20

On 2020-08-09 5:35 p.m., Jonathan Morton wrote:

Are the risks and tradeoffs well enough understood (and visibl=
e enough=20
for troubleshooting) to recommend broader deployment?

I recently gave openwrt a try on some hardware that I ultimately=20
concluded was insufficient for the job.  Fairly soon after changing out=20
my access point, I started getting complaints of Wi-Fi dropping in my=20
household, especially when someone was trying to videoconference.  I=20
discovered that my AP was spontaneously rebooting, and the box was=20
getting hot.

Most CPE devices these days rely on hardware accelerated packet =
forwarding to achieve their published specs.  That's all about taking p=
ackets in one side and pushing them out the other as quickly as possible, w=
ith only minimal support from the CPU (likely, new connections get a NAT/fi=
rewall lookup, that's all).  It has the advantages of speed and power e=
fficiency, but unfortunately it is also incompatible with our debloating ef=
forts.  So debloated CPE will tend to run hotter and with lower peak throug=
hput, which may be noticeable to cable and fibre users; VDSL (FTTC) users m=
ight have service of 80Mbps or less where this effect is less likely to mat=
ter.

It sounds like that AP had a very marginal thermal design which caused the =
hardware to overheat as soon as the CPU was under significant load, which i=
t can easily be when a shaper and AQM are running on it at high throughput.=
  The cure is to use better designed hardware, though you could also contem=
plate breaking the case open to cure the thermal problem directly.  There a=
re some known reliable models which could be collected into a list.  As a r=
ule of thumb, the ones based on ARM cores are likely to be designed with CP=
U performance more in mind than those with MIPS.

Cake has some features which can be used to support explicit classification=
 and (de)prioritisation of traffic via firewall marking rules, either by re=
writing the Diffserv field or by associating metadata with packets within t=
he network stack (fwmark).  This can be very useful for pushing Bittorrent =
or WinUpdate swarm traffic out of the way.  But for most situations, the de=
fault flow-isolating behaviour already works pretty well, especially for en=
suring that one computer's network load has only a bounded effect on an=
y other.  We can discuss that in more detail if that would be helpful.

I'm primarily thinking of this week's ve= rsion of the home router problem (;-))

Because of the degree to which we're working from home and videoconferencing, a lot of low-price, medium-performance devices are suddenly too wimpy for their new role.

A (very!) draft vers= ion is up in Google docs, at https://docs.google.c= om/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BUK0Ju9w/edit?usp=3Dshari= ng

Using myself as the guinea-pig, running pfifo-fast was clearly bad, fq_codel was better, and cake was good with a newish Fedora and the stock Rogers router.=C2=A0 It's been a while since I did = rrul tests, and in any case, I think that to convince readers we need a very practical way of making it clear that they have a problem. I'm thinking that making VOIP fail might do the trick (;-))

The hard part, IMHO, is constructing a test that immediately communicates the idea that the reader has a problem, and that CAKE addresses it.

Returning to the hardware question, https://evenroute.com/iqrv3 seems to be capable of handling up to ~300 Mbit/S connections, and my ISP only delivers 170 (and advertises 150, which is mildly surprising!)

I just ordered one, so I'll have a 'plug i= n" example, along with reflashing my linksys for the umpty-thousandth time.

--dave


=C2=A0I suspect not enough people= are aware of the later efforts of the bufferbloat team, so I'm thinking of one or two articles, starting with LWN and an audience of aficionados.

The core community is aware of what we've done, but in my view we haven't converted "grandma". Grandma, as well as a= whole bunch of ordinary engineers and partners of engineers, are dependent on debloated performance because they're working at home now, and competing with granddaughter playing video games while they're trying to hold a video call.

Right now, my colleagues at work suffer from more than a second of bloat-related lag. They therefore tend to speak over each other on con-calls, apologize, start again and talk over each other, again. After a little while, the picture becomes a distinctly silly one: a bunch of grown adults putting their hands up and waving, like little kids in school. No-one has called out =E2=80=9Cme, me, teacher=E2=80=9D yet, but I expect it a= ny time.

I propose we show the results in terms that we can explain to Grandma, specifically concentrating on functioning VOIP. I just upgraded to Fedora 31, and the networking is absolutely stock, so I make a perfect victim/guinea-pig (;-))

Who's interested? 




--=20
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net<=
/a>           |                      -- Mark Twain
_______________________________________________
Bloat mailing list
Bloat@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
=

__________________________________= _____________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


--
Carlos Pasqualini
+5493454040137
Administraci=C3=B3n de Redes

--00000000000006daf405ac8ac1dc--