Re: [Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Livingood, Jason via Bloat]

On 5/22/24, 09:11, "Sebastian Moeller" mailto:moell...@gmx.de>> wrote:
>[SM] The solution is IMHO not to try to enforce rfc7282 

[JL] ISTM that the things in 7282 are well reflected in how TSVWG operates. I 
know from experience it can be hard when rough consensus doesn't go your way - 
it happens. And at the end of the day there are always competing technical 
solutions - and if L4S indeed does not scale up well and demonstrate sufficient 
benefit (or demonstrate downside) then something else will win the day. 


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

Re: [Bloat] Fwd: "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Livingood, Jason via Bloat]

> in the IETF the gap between the 'no politics' motto

There have always been politics at the IETF and in every other SDO, open source 
project, etc. – it is human nature IMO.

> And the fact that WG members see no harm in having private only strategy 
> discussions with chairs and ADs.

In my personal experience at the IETF, when you are lead author or editor of a 
working group document it is routine to strategize with WG chairs and even ADs 
on how to keep the document moving forward, how to resolve conflict and achieve 
consensus, and how to be well-prepared for meetings. That IMO is a sign of WG 
chairs and ADs doing their job of developing standards on a timely basis.


JL


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

Re: [Bloat] [EXTERNAL] Re: "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Livingood, Jason via Bloat]

> I don't dispute that, at least insofar as the metrics you prefer for such 
> comparisons, under the network conditions you also prefer. But by omitting 
> the conventional AQM results from the performance charts, the comparison 
> presented to readers is not between L4S and the current state of the art, and 
> the expected benefit is therefore exaggerated in a misleading way.

[JL] That is good feedback for you to send to Nokia. But as I mentioned, all 
our comparisons in lab and field testing are of AQM vs L4S - so we have that 
covered (and lots of other tests cases I won't cover here). 




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

Re: [Bloat] [EXTERNAL] Re: "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Livingood, Jason via Bloat]

[SM] Here is Pete's data showing that, the middle two bars show what happens 
when the bottleneck is not treating TCP Prague to the expected signalling... 
That is not really fit for use over the open internet...

[JL] That graph is not anything like what we’ve seen in lab or field testing. I 
suspect you may have made some bad assumptions in the simulation.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Livingood, Jason via Bloat]

On 5/21/24, 12:19, "Bloat on behalf of Jonathan Morton via Bloat wrote:

> Notice in particular that the only *performance* comparisons they make are 
> between L4S and no AQM at all, not between L4S and conventional AQM - even 
> though they now mention that the latter *exists*. 

I cannot speak to the Nokia deck. But in our field trials we have certainly 
compared single queue AQM to L4S, and L4S flows perform better. 

> There's also no mention whatsoever of what happens when L4S traffic meets a 
> conventional AQM.

We also tested this and all is well; the performance of classic queue with AQM 
is fine. 

Jason



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

Re: [Bloat] WiFi

[Livingood, Jason via Bloat]

Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain is 
certainly different than IP, so typical IP CCs don’t apply. In our L4S/NQB 
trials, we put LL-marked packets into the AC_VI WMM queue in the Wi-Fi network. 
IMO there is more work in 802.11 to focus on latency – so much focus right now 
is on throughput over everything else.

From: Starlink  on behalf of Rich Brown 
via Starlink 
Reply-To: Rich Brown 
Date: Wednesday, May 8, 2024 at 07:33
To: David Fernández 
Cc: starlink , bloat 

Subject: Re: [Starlink] [Bloat] L4S

Let's split this thread and use this message to continue the discussion of L4S. 
Thanks


On May 8, 2024, at 5:31 AM, David Fernández via Starlink 
mailto:starl...@lists.bufferbloat.net>> wrote:

I see that L4S is not really solving everything (I read about issues with 
Wi-Fi), although it seems to be a step in the right direction, to be improved, 
let's hope.

At least, Nokia is implementing it in its network gear (for mobile operators), 
so the bufferbloat problem is somehow acknowledged by industry, at least 
initially or partially.

I have seen two consecutive RFCs to 9330:
https://www.rfc-editor.org/info/rfc9331
https://www.rfc-editor.org/info/rfc9332

I suspect that optimal results require the bufferbloat to be addressed not only 
at network layer (IP), but also with some pipelining or cross-layering at link 
level (Ethernet, Wi-Fi or any other link technology, such as 5G, SATCOM, VHF...)

Regards,

David F.

Date: Tue, 7 May 2024 08:46:03 -0400
From: Dave Collier-Brown 
mailto:dave.collier-br...@indexexchange.com>>
To: starl...@lists.bufferbloat.net
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: 
<3d6bdccf-e3d1-4f62-a029-25bfd1f45...@indexexchange.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

It has an RFC at 
https://datatracker.ietf.org/doc/rfc9330/

I read it as a way to rapidly find the available bandwidth without the TCP 
"sawtooth". The paper cites fc_codel and research based on it.

I suspect My Smarter Colleagues know more (;-))

--dave



On 2024-05-07 08:13, David Fernández via Starlink wrote:
Is L4S a solution to bufferbloat? I have read that gamers are happy with it.

Sorry, I read it here, in Spanish:
https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone

Regards,

David F.
___
Starlink mailing list
starl...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


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

Re: [Bloat] [Rpm] [Starlink] [LibreQoS] net neutrality back in the news

[Livingood, Jason via Bloat]

On 9/29/23, 09:29, "Rich Brown" mailto:richb.hano...@gmail.com>> wrote:
> Thank you Jonathan for this clear description of the issues and their 
> history. I wonder if there's a fourth one - privacy. 
> Rosenworcel's talk also points out that ISPs might want to monetize our 
> traffic patterns and location data. (This is less of an issue in the EU, but 
> the US remains a Wild West in this regard.) 

That reference is to mobile networks in the US - but the US-EU contrast you 
make is a good one! The EU IMO does privacy right - it is not sector-specific 
regulation but is general privacy protecting law that protects user data no 
matter the entity collecting/aggregating/sharing. In the US we seem to pursue 
sector-specific privacy law - like specific to credit cards. What we end up 
with is a real mess and I would love to see comprehensive national data privacy 
legislation - but our legislative body can’t even agree right now to keep our 
government funded past this coming Sunday. ;-)

IANAL but it seems like if the US wanted to provide comprehensive location data 
privacy then it would have a uniform law that applied not just to a MNO with 
towers that can locate a handset, but also what the apps loaded on that handset 
with access to GPS can do with the data as well - and any other party that 
might be able to collect data.

JL 


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

Re: [Bloat] [Starlink] [LibreQoS] [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

On 9/29/23, 00:54, "Jonathan Morton" mailto:chromati...@gmail.com>> wrote:
> Some ISPs began to actively degrade Netflix traffic, in particular by 
> refusing to provision adequate peering capacity at the nodes through which 
> Netflix traffic predominated

That is not true and really not worth re-litigating here. 

> NN regulations forced ISPs to carry Netflix traffic with reasonable levels of 
> service, even though they didn't want to for purely selfish and greedy 
> commercial reasons. 

NN regulations played no role whatsoever in the resolution of that conflict - a 
business arrangement was reached, just as it was in the SK Telecom example 
recently: 
https://about.netflix.com/en/news/sk-telecom-sk-broadband-and-netflix-establish-strategic-partnership-to
 

> ISPs behind L4S actively do not want a technology that works end-to-end over 
> the general Internet. 

That's simply not true. As someone running an L4S field trial right now - we 
want the technology to get the widest possible deployment and be fully 
end-to-end. Why else would there be so much effort to ensure that ECN and DSCP 
marks can traverse network domain boundaries for example? Why else would there 
be strong app developer interest? What evidence do you have to show that anyone 
working on L4S want to create a walled garden? If anything, it seems the 
opposite of 5G network slicing, which seems to me personally to be another 3GPP 
run at walled garden stuff (like IMS). Ultimately it is like a lot of other 
IETF work -- it is an interesting technology and we'll have to see whether it 
gets good adoption - the 'market' will decide. 

> They want something that can provide a domination service within their own 
> walled gardens. 

Also not correct. And last time I checked the balance sheets of companies in 
these sectors - video streaming services were losing money while provision of 
internet services were financially healthy. 

JL



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

Re: [Bloat] [EXTERNAL] Re: [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

I forgot to add - the workshop has a great summary at 
https://www.rfc-editor.org/rfc/rfc5594.html

On 9/28/23, 17:07, "Livingood, Jason" mailto:jason_living...@cable.comcast.com>> wrote:


On 9/28/23, 16:06, "Sebastian Moeller" mailto:moell...@gmx.de> >> 
wrote:
>> The answer ended up being a mix of more capacity, apps being more responsive 
>> to other LAN demands, and then advancements in congestion control & queuing. 
>> But there were many customers who were basically self-congesting w/P2P and 
>> VoIP running in their home. 


> [SM] So is it fair to say that the problam was also caused by a rapidly 
> change in usage profiles or was that the smaller problem, if at all a problem?


It was certainly a problem. Like I said, a combination of factors. Certainly 
though, P2P (and it's associated aggressive underlying protocol) was huge - 
estimated at 70% of traffic volume in 2006. 
https://www.plagiarismtoday.com/2017/06/01/the-long-slow-decline-of-bittorrent/ 



Side note - a lot of IETF work flowed from the P2P workshop the IETF held in 
response to all this, including new WGs - LEDBAT, ALTO, CDNI.


JL


PS - some of the P2P workshop papers would be interesting to read again if we 
could find them:


[1] Nick Weaver - The case for "Ugly Now" User Fairness


[2] Paul Jessop - Position paper of the RIAA


[3] Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES:
Edge Capacity Hosting Overlays of Nano Data Centers


[4] Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer
Selection Guidance


[5] Marie-Jose Montpetit - Community Networks: getting P2P out of prison
- the next steps


[6] D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related
Attributes of App Scenarios for P2PSIP


[7] Jiang XingFeng - Analysis of the Service Discovery in DHT network


[8] R. Penno - P2P Status and Requirements


[9] Patrick Crowley and Shakir James - Symbiotic P2P: Resolving the
conflict between ISPs and BitTorrent through mutual cooperation


[10] Robb Topolski - Framing Peer to Peer File Sharing


[11] M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network
Cooperative Overlay System


[12] Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer,
Tracker-Based Peer-to-Peer Content Distribution Architecture


[13] Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind
Krishnamurthy, Laird Popkin - P4P: Provider Portal for P2P Applications


[14] Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly
Peer-to-Peer Services


[15] Camiant (Jackson) - Camiant Submission


[16] Jason Livingood, Rich Woundy - Comcast Submission


[17] Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load
Impact


[18] Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences"


[19] Jiang XingFeng, Ning Zong - Content Replication for Internet P2P
Applications


[20] Sandvine (Dundas) - Analysis of Traffic Demographics in Broadbank
networks


[21] Sandvine (Dundas) - Traffic Management in a World with Network
Neutrality


[22] Stanislav Shalunov - Users want P2P, we make it work


[23] R. Cuevas, A. Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet
scale mobility service: a case study on building a DHT based service for
ISPs


[24] M. Barnes, B. McCormick - Peer to Peer Infrastructure
Considerations


[25] Henning Schulzrinne - Encouraging Bandwidth Efficiency for
Peer-to-Peer Applications


[26] Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri
Papdimitriou - Towards an Open Path Selection Architecture


[27] Eric Rescorla - Notes on P2P Blocking and Evasion


[28] Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P
Systems


[29] Enrico Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco
Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the
Application-Layer Traffic Optimization Problem and the Need for Layer
Cooperation


[30] Tony Moncaster, Bob Briscoe, Louise Burness - Is There a Problem
With Peer-to-peer Traffic?


[31] David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure
Considerations


[32] Bob Briscoe, Lou Burness, Tony Moncaster, Phil Eardley - Solving
this traffic management problem... and the next, and the next





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

Re: [Bloat] [EXTERNAL] Re: [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

On 9/28/23, 16:06, "Sebastian Moeller" mailto:moell...@gmx.de>> wrote:
>> The answer ended up being a mix of more capacity, apps being more responsive 
>> to other LAN demands, and then advancements in congestion control & queuing. 
>> But there were many customers who were basically self-congesting w/P2P and 
>> VoIP running in their home. 

> [SM] So is it fair to say that the problam was also caused by a rapidly 
> change in usage profiles or was that the smaller problem, if at all a problem?

It was certainly a problem. Like I said, a combination of factors. Certainly 
though, P2P (and it's associated aggressive underlying protocol) was huge - 
estimated at 70% of traffic volume in 2006. 
https://www.plagiarismtoday.com/2017/06/01/the-long-slow-decline-of-bittorrent/

Side note - a lot of IETF work flowed from the P2P workshop the IETF held in 
response to all this, including new WGs - LEDBAT, ALTO, CDNI.

JL

PS - some of the P2P workshop papers would be interesting to read again if we 
could find them:

[1] Nick Weaver - The case for "Ugly Now" User Fairness

[2] Paul Jessop - Position paper of the RIAA

[3] Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES:
Edge Capacity Hosting Overlays of Nano Data Centers

[4] Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer
Selection Guidance

[5] Marie-Jose Montpetit - Community Networks: getting P2P out of prison
- the next steps

[6] D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related
Attributes of App Scenarios for P2PSIP

[7] Jiang XingFeng - Analysis of the Service Discovery in DHT network

[8] R. Penno - P2P Status and Requirements

[9] Patrick Crowley and Shakir James - Symbiotic P2P: Resolving the
conflict between ISPs and BitTorrent through mutual cooperation

[10] Robb Topolski  - Framing Peer to Peer File Sharing

[11] M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network
Cooperative Overlay System

[12] Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer,
Tracker-Based Peer-to-Peer Content Distribution Architecture

[13] Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind
Krishnamurthy, Laird Popkin - P4P: Provider Portal for P2P Applications

[14] Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly
Peer-to-Peer Services

[15] Camiant (Jackson) - Camiant Submission

[16] Jason Livingood, Rich Woundy - Comcast Submission

[17] Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load
Impact

[18] Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences"

[19] Jiang XingFeng, Ning Zong - Content Replication for Internet P2P
Applications

[20] Sandvine (Dundas) - Analysis of Traffic Demographics in Broadbank
networks

[21] Sandvine (Dundas) - Traffic  Management in a World with Network
Neutrality

[22] Stanislav Shalunov - Users want P2P, we make it work

[23] R. Cuevas, A. Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet
scale mobility service: a case study on building a DHT based service for
ISPs

[24] M. Barnes, B. McCormick - Peer to Peer Infrastructure
Considerations

[25] Henning Schulzrinne - Encouraging Bandwidth Efficiency for
Peer-to-Peer Applications

[26] Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri
Papdimitriou - Towards an Open Path Selection Architecture

[27] Eric Rescorla - Notes on P2P Blocking and Evasion

[28] Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P
Systems

[29] Enrico Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco
Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the
Application-Layer Traffic Optimization Problem and the Need for Layer
Cooperation

[30] Tony Moncaster, Bob Briscoe, Louise Burness - Is There a Problem
With Peer-to-peer Traffic?

[31] David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure
Considerations

[32] Bob Briscoe, Lou Burness, Tony Moncaster, Phil Eardley - Solving
this traffic management problem... and the next, and the next

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

Re: [Bloat] [LibreQoS] [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

> From: Bloat  on behalf of Jeremy Austin 
> via Bloat 

> I'm interested in seeing how one can enforce the 'will of the people' -- the 
> application vendors (who are doing everything in their power to prevent ISPs 
> identifying *anything* about the traffic) will certainly not obey such a 
> will, and the ISP can in good faith implement such a prioritization service 
> but have no power to cryptographically authenticate such traffic. This seems 
> a dead end where no one is willing to bear the cost.

Great point! Back in the old days, sure you could use DPI to identify flow X as 
streaming video, flow Y as web traffic, and flow Z as email. No more - based on 
3rd party stats somewhere between 90% - 95% of traffic is encrypted (increasing 
all the time) -- so no more ability to accurately infer application type and 
trigger a network response based on that. 

Great doc on the shift to pervasive encryption: 
https://www.rfc-editor.org/rfc/rfc9446.html "Reflections on Ten Years Past the 
Snowden Revelations"

JL 





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

Re: [Bloat] [Starlink] [LibreQoS] [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

> dan  wrote: 

> "(I assume most ISPs want happy customers)."
made me laugh a little.  'Most' by quantity of businesses maybe, but 'most' in 
terms of customers being served by puts the Spectrums and Comcasts in the mix 
(in the US) and they don't care about happy customers they care about defacto 
monopolies in markets so that they don't have to care about happy customers.  

Corporations are motivated to generate returns for investors. In that context, 
happy customers stay longer (less churn) and spend more (upgrades, multiple 
services). And unhappy customers generate costs via disconnects (loss of 
revenue, costs to replace them with a new customer to just stay at the same 
subscriber levels), and costs via customer contacts (call center staff). So, 
IMO on a purely financial basis, public companies have significant motivation 
to retain customers and keep them happy. This typically follows through to 
staff members having part of their variable compensation based on things like 
NPS scores, contact rates, etc. And specifically in relation to Comcast, the 
company recently has 4 new wireless competitors: three 5G FWA and one LEO (more 
coming) - and those are posing significant competitive risks (and taking 
customers). 

> For the last mile, I'm actually less concerned with pure NN and more 
> concerned with no-blocking or 'brand' prioritization and required/label 
> transparency...

The two thoughts your comments (thanks for the response BTW!) trigger are:
1 - Often regulation looks to the past - in this case maybe an era of bandwidth 
scarcity where prioritization may have mattered. I think we're in the midst of 
a shift into bandwidth abundance where priority does not matter. What will is 
latency/responsiveness, content/compute localization, reliability, consistency, 
security, etc. 
2 - If an ISP blocked YouTube or Netflix, they'd incur huge customer care 
(contact) costs and would see people start to immediately shift to competitors 
(5G FWA, FTTP or DOCSIS, WISP, Starlink/LEO, etc.). It just does not seem like 
something that could realistically happen any longer in the US.

JL




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

Re: [Bloat] [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

On 9/28/23, 02:25, "Bloat on behalf of Sebastian Moeller via Bloat" 
mailto:bloat-boun...@lists.bufferbloat.net> on behalf of 
bloat@lists.bufferbloat.net > wrote:
> But the core issue IMHO really was an economic one, the over-subscription 
> ratios that worked before torrenting simply did not cut it any more in an 
> environment when customers actually tried to use their contracted access 
> rates "quantitatively". 

It was more complicated than that. At least in cable networks it came at the 
end of single channel DOCSIS 2.0 devices, as cable upgraded to channel bonding 
in DOCSIS 3.0 - which to your point brought dramatic increases in capacity. 
That was happening at the same time P2P was becoming popular. On the other 
hand, customers were congesting their own connections pretty pervasively - 
trying to use VoIP while their P2P client was active. At the time the P2P 
protocol tended to be pretty aggressive and smothered real-time apps (if you 
gave the client 1 Mbps US it would use it, if 10 Mbps - used that 100% as well, 
25 Mbps - same, etc.). 

The answer ended up being a mix of more capacity, apps being more responsive to 
other LAN demands, and then advancements in congestion control & queuing.  But 
there were many customers who were basically self-congesting w/P2P and VoIP 
running in their home. 

> but this is why e.g. my bit torrent could affect your VoIP, simply by pushing 
> the whole segment into upload capacity congestion... (ISPs in theory could 
> fix this by plain old QoS engineering, but the issue at hand was with a 
> non-ISP VoIP/SIP service and there QoS becomes tricky if the ISP as these 
> packets need to be identified in a way that is not game-able**)

Sure - for their own (nascent & small scale) digital voice products. But to 3rd 
party VoIP - no one then was really doing inter-domain DSCP marking end-to-end 
(still are not). The non-ISP offering here was the big driver of consumer 
complaints.

> ) This is not to diss the press, they are doing what they are supposed to 
> do, but it just shows that active regulation is a tricky business, and a 
> light touch typically "looks better" (even though I see no real evidence it 
> actually works better).

It's not made easier in the US where one can strongly support formal national 
NN rules but be against putting it under Title-II regulation vs. Title-I. IANAL 
so cannot properly explain the nuances. Ultimately legislation is the best 
solution, as this will just be in the courts for years, but our US Congress is 
not the most functional body these days and people have tried to do legislation 
for many years. 

Jason

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

Re: [Bloat] [Starlink] [Rpm] net neutrality back in the news

[Livingood, Jason via Bloat]

On 9/28/23, 12:45, "Starlink on behalf of Dave Taht via Starlink" 
mailto:starlink-boun...@lists.bufferbloat.net> on behalf of 
starl...@lists.bufferbloat.net > wrote:
> It would be nice, if as a (dis)organisation... the bufferbloat team
could focus on somehow getting both sides of the network neutrality
debate deeplying understanding the technological problem their
pre-conceptions face, and the (now readily available and inexpensive)
solutions that could be deployed, by most ISPs, over a weekend. We are
regularly bringing up a few thousand people a week on libreqos (that
we know of), and then of course, there are all the home routers and
CPE that are increasingly capable of doing the right thing.

[JL] The FCC will soon (maybe today) open a notice of proposed rulemaking - aka 
NPRM. That process provides an opportunity for anyone to file and filings from 
technical experts are always highly valued. 




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

[Bloat] Testing Offer - Comcast L4S Trials

[Livingood, Jason via Bloat]

As noted recently, we (Comcast) will soon begin L4S testing with customers. 
We’re working on our test plans now. So my offer here is to let me know if:
1 – You have test probes you’d like us to deploy. We are working on a plan to 
send out (1) University of Chicago NetMicroscope probes and (2) RIPE Atlas 
probes.
2 – You have web-based tests you’d like people to run, or have one-click 
install client for Mac or Windows. (Most testers will not be technical enough 
to run CLI-based tests, the the exception of the Apple network responsiveness 
test.)

Thx! If this is of interest, please ping me 1:1 off-list.
Jason

Current list
(1.a) Ookla web-based
(1.b) Ookla client
(1.c) M-Labs NDT
(1.d) Fastly web-based
(1.e) Netflix web-based
(1.f) Waveform web-based
(1.g) DSL Reports web-based
(1.h) Apple Network Responsiveness test

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

[Bloat] Inform: Volunteer for Comcast Field Trials

[Livingood, Jason via Bloat]

FYI that today we (Comcast) have announced the start of low latency networking 
(L4S) field trials. If you are a customer and would like to volunteer, please 
visit this 
page.

For more info, there is a blog post that just went up at 
https://corporate.comcast.com/stories/comcast-kicks-off-industrys-first-low-latency-docsis-field-trials

We anticipate testing with several different cable modems and a range of 
applications that are marking. We plan to share detailed results of the trial 
at IETF-118 in November.

Any app developers interested in working with us can either email me direction 
or 
low-latency-partner-inter...@comcast.com.

Thanks!
Jason




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

Re: [Bloat] Net Job

[Livingood, Jason via Bloat]

That role reports to me – folks can ping me 1:1 if they have Qs. :-)

From: Bloat  on behalf of "Carlin, Tim via 
Bloat" 
Reply-To: "Carlin, Tim" 
Date: Friday, March 31, 2023 at 04:02
To: "bloat@lists.bufferbloat.net" 
Subject: [Bloat] Net Job

At the risk of one more related though off-topic post here's an opportunity to 
help define the future network:

https://jobs.comcast.com/jobs/description/tpx-jd-template?external_or_internal=External&job_id=R352105#section-job-description

I don't know anything about Comcast or the job...this just passed through my LI.



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

Re: [Bloat] [Starlink] On fiber as critical infrastructure w/Comcast chat

[Livingood, Jason via Bloat]

Happy to help (you can ping me off-list). The main products are DOCSIS and PON 
these days and it kind of depends where you are, whether it is a new build, 
etc. As others said, it gets super complicated in MDUs and the infrastructure 
in place and the building agreements vary quite a bit.

Jason

From: Bloat  on behalf of Nathan Owens via 
Bloat 
Reply-To: Nathan Owens 
Date: Sunday, March 26, 2023 at 09:07
To: Robert McMahon 
Cc: Rpm , dan , Frantisek 
Borsik , Bruce Perens , libreqos 
, Dave Taht via Starlink 
, bloat 
Subject: Re: [Bloat] [Starlink] On fiber as critical infrastructure w/Comcast 
chat

Comcast's 6Gbps service is a niche product with probably <1000 customers. It 
requires knowledge and persistence from the customer to actually get it 
installed, a process that can take many months (It's basically MetroE). It 
requires you to be within 1760ft of available fiber, with some limit on install 
cost if trenching is required. In some cases, you may be able to trench 
yourself, or cover some of the costs (usually thousands to tens of thousands).

On Sat, Mar 25, 2023 at 5:04 PM Robert McMahon via Bloat 
mailto:bloat@lists.bufferbloat.net>> wrote:
The primary cost is the optics. That's why they're p in sfp and pay go
Bob
On Mar 25, 2023, at 4:35 PM, David Lang mailto:da...@lang.hm>> 
wrote:

On Sat, 25 Mar 2023, Robert McMahon via Bloat wrote:

 The fiber has basically infinite capacity.

in theory, but once you start aggregating it and having to pay for equipment
that can handle the rates, your 'infinite capaicty' starts to run out really
fast.

David Lang



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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Another Measurement Program

[Livingood, Jason via Bloat]

FWIW, just heard from Ann and Wesley (cc’d) that they are well below their 
target numbers (16 signups of a 120 target). So just throwing this out there 
again….

Jason

From: "Livingood, Jason" 
Date: Monday, February 20, 2023 at 11:14
To: Dave Taht via Bloat 
Subject: Another Measurement Program

When it rains, it pours… There's another measurement program focused on fixed 
wireless (LEO and 5G) - in addition to others I have posted the last few 
months. Signup is at https://measuringwirelessamerica.com/signup

Personally – looking forward to ~6 months from now when all these various 
programs start to present papers & share data / results.

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

Re: [Bloat] [EXTERNAL] Re: Another Measurement Program

[Livingood, Jason via Bloat]

> My principal issue with all this wonderful activity, is I would like,
rather desparately, for all the researchers involved to discuss their
methods, and try to calibrate them against a reference of some kind.

I think researchers & industry are in the 'storming' phase and not yet ready 
for 'norming', so to speak. It will probably happen in time. As papers come 
out, it will be helpful to examine methodologies & learn from them to move the 
state of the art forward. 

> Is anyone testing videoconferencing quality? A mere MOS out of
videoconferencing traffic relative to other load would please me.

I think SamKnows have a video streaming quality test [1]. And IIRC there is 
research into passive measurement of video streams to infer quality, but I 
don’t recall any recent papers off hand. 

Jason

[1] See:
https://samknows.com/tests/video-streaming 
https://samknows.com/blog/new-streaming-test
https://samknows.com/blog/critical-services-tracker-video-streaming-uk


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

[Bloat] Another Measurement Program

[Livingood, Jason via Bloat]

When it rains, it pours… There's another measurement program focused on fixed 
wireless (LEO and 5G) - in addition to others I have posted the last few 
months. Signup is at https://measuringwirelessamerica.com/signup

Personally – looking forward to ~6 months from now when all these various 
programs start to present papers & share data / results.

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

[Bloat] Good Podcasts & Reporters?

[Livingood, Jason via Bloat]

As I work on our planned field trials of low latency network improvements, I am 
building a list of possible podcasts to talk to & reporters. Any suggestions 
for ones with whom to talk? I know Doc Searls has interviewed Dave before, so 
his podcast might be interested. Any other suggestions from folks here?

Thanks!
Jason
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Another BB measurement program - U Chicago

[Livingood, Jason via Bloat]

Since I have posted about a few other recent measurement programs looking for 
testers – especially those targeting LEO networks a testing latency – here’s 
one more. This one is recruiting to test growing fixed wireless networks (LEO & 
5G), expanding prior studies they have done in wireline networks. It is led by 
Nick Feamster at the University of Chicago, 
using his NetMicroscope platform (cc’d in case anyone has technical questions). 
To volunteer (if you use Starlink or a 5G fixed wireless ISP) – fill in the 
form at  
https://uchicago.co1.qualtrics.com/jfe/form/SV_eCFrZhRhNphkVGm?jfefe=new



His related work was recently featured here "Mapping the digital divide: Data 
reveals internet inequities across the country" - 
https://news.uchicago.edu/story/mapping-digital-divide-data-reveals-internet-inequities-across-country
 - and many of you probably know of Nick’s work anyway.



Jason



PS – I do believe the tests themselves are or will all be openly documented and 
that raw data may also become available.



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

Re: [Bloat] [EXTERNAL] Re: [Starlink] Researchers Seeking Probe Volunteers in USA

[Livingood, Jason via Bloat]

> 0) None of the tests last long enough.

The user-initiated ones tend to be shorter - likely because the average user 
does not want to wait several minutes for a test to complete. But IMO this is 
where a test platform like SamKnows, Ookla's embedded client, NetMicroscope, 
and others can come in - since they run in the background on some randomized 
schedule w/o user intervention. Thus, the user's time-sensitivity is no longer 
a factor and a longer duration test can be performed.

> 1) Not testing up + down + ping at the same time

You should consider publishing a LUL BCP I-D in the IRTF/IETF - like in IPPM...

JL

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

Re: [Bloat] FCC requires broadband "Nutritional Label"

[Livingood, Jason via Bloat]

On 11/18/22, 07:36, "Bloat on behalf of Rich Brown via Bloat" 
 
wrote:
> Even though the label only specifies "typical latency", I have a sense that 
> this is a good step forward. If your ISP specifies 5 msec as "typical" and 
> their crummy router is bloated, can you get a repair if you call them and say 
> that it's averaging 150msec? 

FWIW I think there's now a further comment period open on the label. I am sure 
comments around (working) latency would be welcome...

Jason


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

Re: [Bloat] [EXTERNAL] Re: Measuring 5G Bloat (Was 5G going south)

[Livingood, Jason via Bloat]

Maybe eventually - but let’s walk before we run and start with 2 so we have a 
sufficient sample size. 

On 10/31/22, 10:25, "Dave Taht"  wrote:

Jason: OK to add a few bleeding edge non-5g fixed wireless networks to the 
mix?

On Mon, Oct 31, 2022 at 7:21 AM Livingood, Jason
 wrote:
>
> FWIW - I'm working with a few measurement networks and researchers that 
are very soon deploying measurement probes - in the US - on 5G fixed wireless 
access connections and LEO (Starlink). These probes range on the low end from 
RIPE Atlas to higher end RPi-based probes. If you are interested in hosting one 
of these probes email me OFF-LIST:
> - Your name
> - Your shipping address
> - Your ISP name [FWA or LEO]
>
> Some of these researchers are ready to ship probes in a couple of weeks 
and I'll have a bunch of RIPE Atlas probes ready to ship in about a month.
>
> Thanks!
> Jason
>
> On 10/28/22, 17:10, "Bloat on behalf of jf--- via Bloat" 
 
wrote:
>
> We’ve observed growing variability on some TMHI setups from our 
fleet, and it seems there is a correlation to usage growth on a single tower. 
Seems neighbors talk to hear other after all ;-)
>
> And yes, horrible bufferbloat on these variable capacity links.
>
> > The author switched to verizon, but what guarantees of continued
> > reliability does one have?
>
> It seems none ATM, as it really depends on user density vs tower 
capacity. Woe to those that share a tower with a busy highway, ‘rush hour’ 
likely means low capacity and even higher latencies.
>
> Cheers,
>
> Jonathan Foulkes
>
>
> > On Oct 27, 2022, at 11:37 PM, Dave Taht via Bloat 
 wrote:
> >
> > This had some details as to the things that could go wrong from an
> > initial happy install of t-mobile, to something terrible.
> >
> > The author switched to verizon, but what guarantees of continued
> > reliability does one have?
> >
> > 
https://urldefense.com/v3/__https://blog.networkprofile.org/redundant-wan-ditching-t-mobile-5g-for-verizon-5g/__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K7-U5YFaQA$
> >
> > (both services had horrible bufferbloat)
> >
> >
> > --
> > This song goes out to all the folk that thought Stadia would work:
> > 
https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K79bh-A5Hw$
> > Dave Täht CEO, TekLibre, LLC
> > ___
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > 
https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K7_OsL72IQ$
>
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> 
https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K7_OsL72IQ$
>


-- 
This song goes out to all the folk that thought Stadia would work:

https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz__;!!CQl3mcHX2A!Cs0pLigD36lDOOcJbbuTiHglNobYkmdKzN5PseCl9k0hPIDWEeuhgLuVUmhRs_q_cPvT1sPy_zTlwn2zLLLOCD5p$
  
Dave Täht CEO, TekLibre, LLC

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

[Bloat] Measuring 5G Bloat (Was 5G going south)

[Livingood, Jason via Bloat]

FWIW - I'm working with a few measurement networks and researchers that are 
very soon deploying measurement probes - in the US - on 5G fixed wireless 
access connections and LEO (Starlink). These probes range on the low end from 
RIPE Atlas to higher end RPi-based probes. If you are interested in hosting one 
of these probes email me OFF-LIST:
- Your name 
- Your shipping address
- Your ISP name [FWA or LEO]

Some of these researchers are ready to ship probes in a couple of weeks and 
I'll have a bunch of RIPE Atlas probes ready to ship in about a month.

Thanks!
Jason

On 10/28/22, 17:10, "Bloat on behalf of jf--- via Bloat" 
 
wrote:

We’ve observed growing variability on some TMHI setups from our fleet, and 
it seems there is a correlation to usage growth on a single tower. Seems 
neighbors talk to hear other after all ;-)

And yes, horrible bufferbloat on these variable capacity links.

> The author switched to verizon, but what guarantees of continued
> reliability does one have?

It seems none ATM, as it really depends on user density vs tower capacity. 
Woe to those that share a tower with a busy highway, ‘rush hour’ likely means 
low capacity and even higher latencies.

Cheers,

Jonathan Foulkes


> On Oct 27, 2022, at 11:37 PM, Dave Taht via Bloat 
 wrote:
> 
> This had some details as to the things that could go wrong from an
> initial happy install of t-mobile, to something terrible.
> 
> The author switched to verizon, but what guarantees of continued
> reliability does one have?
> 
> 
https://urldefense.com/v3/__https://blog.networkprofile.org/redundant-wan-ditching-t-mobile-5g-for-verizon-5g/__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K7-U5YFaQA$
  
> 
> (both services had horrible bufferbloat)
> 
> 
> -- 
> This song goes out to all the folk that thought Stadia would work:
> 
https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K79bh-A5Hw$
  
> Dave Täht CEO, TekLibre, LLC
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> 
https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K7_OsL72IQ$
  

___
Bloat mailing list
Bloat@lists.bufferbloat.net

https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DZPmyvCVso3V5VJsCmkvtzgtr5uBLoBSFpjGmKungaWqn5HKuLeCMgmCPiPY0rYPhiQN3Dl6jLyoUia5Gx94K7_OsL72IQ$
  

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

Re: [Bloat] [Rpm] [Make-wifi-fast] [Cake] The most wonderful video ever about bufferbloat

[Livingood, Jason via Bloat]

> Better is that network engineers "design bloat out" from the beginning 
> starting by properly sizing queues to service jitter, and for WiFi, to also 
> enable aggregation techniques that minimize TXOP consumption.

Maybe – like ‘security by design’ and ‘privacy by design’ – we need ‘low 
latency by design’ for network engineers! ;-)

JL

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

[Bloat] Game Demo Suggestions?

[Livingood, Jason via Bloat]

Some of my colleagues in the office are recording video of gaming with and 
without AQM (bloated vs unbloated), etc. Any suggestions on games that will 
really make this obvious & compelling – something cool and worthy of posting on 
YouTube?

Thanks!
Jason
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Rpm] broadband cost analysis

[Livingood, Jason via Bloat]

On 4/14/22, 11:40, "Bloat on behalf of Rich Brown" 
 
wrote:

>$2K-$4K per premise for the drop cable from the pole and the router in the 
> premise

What is the CPE router? Does it have AQM or some other latency control 
mechanism?

Thx!
Jason


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

[Bloat] FWA Test Results

[Livingood, Jason via Bloat]

This is from a colleague that was using 5G FWA at home. Their computer was 
connected to the gateway via Ethernet and the gateway was next to a glass door 
with LoS to the tower ~0.25 mi away (no tree/leaf or other obstructions). So 
definitely a best case for location in the home & connectivity to the RAN and 
no competing LAN traffic at the time of the test.

https://www.waveform.com/tools/bufferbloat?test-id=55167384-3ee5-4f5d-a1ea-131458b231f6

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

Re: [Bloat] ntia broadband RFC

[Livingood, Jason via Bloat]

In my personal opinion, these agencies are usually quite happy to have comments 
from technical experts. If any of you do make comments, making them concise and 
not too complex will tend to ensure they are widely read and internalized. ;-)

In the details, I could certainly see folks in this community being able to 
credibly comment on question 13 [1] given its mention of latency and quality.

Jason

[1] "What guidance or requirements, if any, should NTIA consider with respect 
to network
reliability and availability, cybersecurity, resiliency, latency, or other 
service quality features and
metrics? What criteria should NTIA establish to assess grant recipients’ plans 
to ensure that service providers maintain and/or exceed thresholds for 
reliability, quality of service, sustainability, upgradability and other 
required service characteristics?"

On 1/18/22, 16:19, "Bloat on behalf of Dave Taht" 
 wrote:

This is the first time in years that I felt that maybe something we
said could get through to an agency of the US government. The deadline
for filing is feb 4th,
and it would be nice if some of the billions on the table got spent on
better routers, software, and networks.


https://urldefense.com/v3/__https://ntia.gov/files/ntia/publications/fr-iija-broadband-rfc.pdf__;!!CQl3mcHX2A!TEn3rSNYwOHZ6E_RnvIDoIT2cXlisfhHkmtpnbIfCiAk63Rac2aqOnzG6nZnLUlLAE9NwQ$

In their RFC there are 36 questions, some of which are pretty good.

I've been participating a bit in this forum:

https://urldefense.com/v3/__https://discuss.broadband.money/c/broadband-grant-events/scott-woods-ama__;!!CQl3mcHX2A!TEn3rSNYwOHZ6E_RnvIDoIT2cXlisfhHkmtpnbIfCiAk63Rac2aqOnzG6nZnLUlnwITAjA$
among other things I dragged out last week was the "upgrade in place"
idea. There's 3 weeks or so to come up with
something worth filing, but as usual these days I'm always looking for
collaborators?



--
I tried to build a better future, a few times:

https://urldefense.com/v3/__https://wayforward.archive.org/?site=https*3A*2F*2Fwww.icei.org__;JSUl!!CQl3mcHX2A!TEn3rSNYwOHZ6E_RnvIDoIT2cXlisfhHkmtpnbIfCiAk63Rac2aqOnzG6nZnLUnbOe7hAA$

Dave Täht CEO, TekLibre, LLC
___
Bloat mailing list
Bloat@lists.bufferbloat.net

https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!TEn3rSNYwOHZ6E_RnvIDoIT2cXlisfhHkmtpnbIfCiAk63Rac2aqOnzG6nZnLUnPllTvyw$

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

Re: [Bloat] [Rpm] Airbnb

[Livingood, Jason via Bloat]

Great news, Matt! If I may make a recommendation, IMO a standalone working 
latency test would have greater utility than integrating such a measurement 
into an existing test & so it may have the opportunity of more widespread usage.

JL

From: Bloat  on behalf of Matt Mathis via 
Bloat 
Reply-To: Matt Mathis 
Date: Tuesday, August 10, 2021 at 00:52
To: "dave.collier-br...@indexexchange.com" 

Cc: bloat 
Subject: Re: [Bloat] [Rpm] Airbnb

I am part of the M-Lab team.

For years we published a "jitter" metric that I considered to be bogus, 
basically max_rtt - min_rtt, (which were builtin Web100 instruments).

In 2019, we transitioned from web100 to "standard" linux tcp_info, which does 
not capture max_rtt.   Since the web100 jitter was viewed as bogus, we did not 
attempt to reconstruct it, although we could have.   Designing and implementing 
a new latency metric was on my todo list from the beginning of that transition, 
but chronically preempted by more pressing problems.

It finally made it to the top of my queue which is why I am suddenly not 
lurking here and the new rpm list.  I was very happy to see the Apple 
responsiveness metric, and realized that M-Lab can implement a TCP version of 
it, that can be computed both in real time on future tests and retroactively 
over archived tests collected over the last 12 years.

This quick paper might be of interest: Preliminary Longitudinal Study of 
Internet 
Responsiveness
.
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 Mon, Aug 9, 2021 at 5:27 PM Dave Collier-Brown 
mailto:dave.collier-br...@indexexchange.com>>
 wrote:

Knowing programmers, I'd more likely assume latency when it's easiest to 
measure. At a guess, either

  *   average of upload or download
  *   average of download (as it comes first)

--dave (call me "Wally" (:-)) c-b



On 2021-08-09 4:24 p.m., Jonathan Morton wrote:

On 9 Aug, 2021, at 10:25 pm, Dave Collier-Brown 

 wrote:



My run of it reported latency, but without any qualifiers...

One would reasonable assume that's idle latency, then.



 - Jonathan Morton

___

Bloat mailing list

Bloat@lists.bufferbloat.net

https://lists.bufferbloat.net/listinfo/bloat

--

David Collier-Brown, | Always do right. This will gratify

System Programmer and Author | some people and astonish the rest

dave.collier-br...@indexexchange.com
 |  -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any 
and all attachments, contains confidential information intended only for the 
person(s) to whom it is addressed. Any dissemination, distribution, copying or 
disclosure is strictly prohibited and is not a waiver of confidentiality. If 
you have received this telecommunication in error, please notify the sender 
immediately by return electronic mail and delete the message from your inbox 
and deleted items folders. This telecommunication does not constitute an 
express or implied agreement to conduct transactions by electronic means, nor 
does it constitute a contract offer, a contract amendment or an acceptance of a 
contract offer. Contract terms contained in this telecommunication are subject 
to legal review and the completion of formal documentation and are not binding 
until same is confirmed in writing and has been signed by an authorized 
signatory.
___
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

Re: [Bloat] Fwd: Airbnb

[Livingood, Jason via Bloat]

Unfortunately this is not an aggregate capacity test but a single connection 
test so I don’t think AirBnB selected a test that is matched to the question 
their prospective guests are interested in. That test certainly has it’s uses 
as a diagnostic tool but perhaps not to say how fast someone’s Internet access 
may be. There’s a recent MIT paper about this that is worth reading: 
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3898339

Jason

From: Bloat  on behalf of Dave Taht 

Date: Saturday, August 7, 2021 at 14:57
To: bloat , "r...@lists.bufferbloat.net" 

Subject: [Bloat] Fwd: Airbnb


Airbnb internet metric:

-- Forwarded message -
From: Simon Barber (sibarber) mailto:sibar...@cisco.com>>
Date: Fri, Jul 30, 2021 at 9:58 AM
Subject: Airbnb
To: dave.t...@gmail.com 
mailto:dave.t...@gmail.com>>

https://news.airbnb.com/new-tool-check-the-wifi-speed-in-your-airbnb-listing-before-you-book/
[https://news.airbnb.com/wp-content/uploads/sites/4/2021/07/PJM013418Q316-Garden_Home-05671_JL1.jpg?fit=2500%2C16671zT%01]

New tool: Check the wifi speed in your Airbnb listing before you 
book
As the growing flexibility to work and live from anywhere continues, being able 
to determine a listing’s wifi speed before booking is a must-have for digital 
nomads, remote workers, roadschoolers, traveling families, gamers, and 
creatives alike.
news.airbnb.com



Wish they measured latency under load to give you a better score of your wifi 
experience!

Simon



--
Fixing Starlink's Latencies: 
https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [EXTERNAL] Re: Of interest: Comcast AQM Paper

[Livingood, Jason via Bloat]

That is the XB3 - see 
https://www.xfinity.com/support/articles/broadband-gateways-userguides. It is 
DOCSIS 3.0 and you should definitely replace it. I will ping you 1:1.

On 8/1/21, 17:01, "Kenneth Porter"  wrote:

--On Sunday, August 01, 2021 9:28 PM + "Livingood, Jason via Bloat"
 wrote:

> The "XB3" definitely lacks it - as it's DOCSIS 3.0-based. You may be
> eligible for a replacement, depending on your speed tier. Take a look at
> 
https://urldefense.com/v3/__https://customer.xfinity.com/*/devices__;Iw!!CQl3mcHX2A!UtxGWv5Ip9TPlLZIevdwcd1p5SZMUHq4XhANtaC17OhRCvEI5YADBjD349c3imPEbenwGA$
  and see what that says. If that
> does not have anything that let's you replace it then send me an email
> 1:1 and I'll assist. Optimally you'll want an XB7 but an XB6 would also
> work fine based on your config. (and I wish it could do more of what you
> need on other areas)

How would I know which one I have? I can't find a model number on it and
the web page "Gateway > Hardware > System Hardware" only shows the base
model number of TG1682G, no suffix. Hardware Revision is 11.0.

I'd also consider buying my own, which might address my DHCP issue if the
downloaded firmware doesn't take that away from me.




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

Re: [Bloat] Of interest: Comcast AQM Paper

[Livingood, Jason via Bloat]

On 8/1/21, 16:13, "Bloat on behalf of Kenneth Porter" 
 wrote:

> Mine is a TG1682G, which I'm betting lacks PIE. So how do we get an upgrade?

The "XB3" definitely lacks it - as it's DOCSIS 3.0-based. You may be eligible 
for a replacement, depending on your speed tier. Take a look at 
https://customer.xfinity.com/#/devices and see what that says. If that does not 
have anything that let's you replace it then send me an email 1:1 and I’ll 
assist. Optimally you'll want an XB7 but an XB6 would also work fine based on 
your config. (and I wish it could do more of what you need on other areas)

JL

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

Re: [Bloat] Of interest: Comcast AQM Paper

[Livingood, Jason via Bloat]

Should be for COAM and leased. If you are having issues – you can email me 1:1 
at this work address. Please include your modem make/model and account # so I 
can investigate. :-)

JL

From: Aaron Wood 
Date: Saturday, July 31, 2021 at 15:27
To: Simon Barber 
Cc: "Livingood, Jason" , 
"starl...@lists.bufferbloat.net" , bloat 

Subject: [EXTERNAL] Re: [Bloat] Of interest: Comcast AQM Paper

If we see that AQM appears to be not functioning as expected for upstream 
connections on DOCSIS3.1, what's the right avenue for getting that resolved?  
(and does that only apply to the Comcast-owned, vs. customer-owned, modems?)

On Sat, Jul 31, 2021 at 10:50 AM Simon Barber 
mailto:si...@superduper.net>> wrote:
Awesome to hear that you are turning this on both upstream and downstream. Do 
you know if the wifi stacks in your home routers also have AQM?

Simon


> On Jul 30, 2021, at 10:28 PM, Livingood, Jason via Bloat 
> mailto:bloat@lists.bufferbloat.net>> wrote:
>
> FYI that I will be presenting a lightning talk at the IRTF MAPRG meeting 
> today at 17:30 ET 
> (https://datatracker.ietf.org/meeting/111/materials/agenda-111-maprg<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/agenda-111-maprg__;!!CQl3mcHX2A!Rz15R4ZotXRWgIwMICwg0hP8rUn_zYmu7Xj_ujBrgBBYt5p7D8wGY4Toi7StQUQRf1LEmw$>).
>  The talk links to a just-published paper at 
> https://arxiv.org/abs/2107.13968<https://urldefense.com/v3/__https:/arxiv.org/abs/2107.13968__;!!CQl3mcHX2A!Rz15R4ZotXRWgIwMICwg0hP8rUn_zYmu7Xj_ujBrgBBYt5p7D8wGY4Toi7StQUSKQx-diA$>
>  (click PDF link in upper right of page) that will likely be of interest to 
> these two lists.
>
> High-level: turning on AQM in the cable modem (upstream queue) took working 
> latency from around 250 ms to between 15-30 ms, which is actually kind of 
> cool. ;-) AQM is turned on in all of our CMTSes (downstream queue) and in 
> DOCSIS 3.1 modems (upstream queue).
>
> Have a nice weekend,
> Jason
>
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net<mailto:Bloat@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat<https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!Rz15R4ZotXRWgIwMICwg0hP8rUn_zYmu7Xj_ujBrgBBYt5p7D8wGY4Toi7StQUQ2nBiSiA$>

___
Bloat mailing list
Bloat@lists.bufferbloat.net<mailto:Bloat@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/bloat<https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!Rz15R4ZotXRWgIwMICwg0hP8rUn_zYmu7Xj_ujBrgBBYt5p7D8wGY4Toi7StQUQ2nBiSiA$>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Of interest: Comcast AQM Paper

[Livingood, Jason via Bloat]

WiFi is a different challenge as you know. In this case it varies depending on 
the radio chipset vendor and is on my list of things to work on...

JL

On 7/31/21, 13:50, "Simon Barber"  wrote:

Awesome to hear that you are turning this on both upstream and downstream. 
Do you know if the wifi stacks in your home routers also have AQM?

Simon


> On Jul 30, 2021, at 10:28 PM, Livingood, Jason via Bloat 
 wrote:
>
> FYI that I will be presenting a lightning talk at the IRTF MAPRG meeting 
today at 17:30 ET 
(https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/111/materials/agenda-111-maprg__;!!CQl3mcHX2A!XLFMYPw-gnJgHzz_1nF-N7dNeIeT4QD-5wQny8vdAfYE6bzHtVQD3-lqiQI9YwAncrZUew$
 ). The talk links to a just-published paper at 
https://urldefense.com/v3/__https://arxiv.org/abs/2107.13968__;!!CQl3mcHX2A!XLFMYPw-gnJgHzz_1nF-N7dNeIeT4QD-5wQny8vdAfYE6bzHtVQD3-lqiQI9YwCePfNyng$
  (click PDF link in upper right of page) that will likely be of interest to 
these two lists.
>
> High-level: turning on AQM in the cable modem (upstream queue) took 
working latency from around 250 ms to between 15-30 ms, which is actually kind 
of cool. ;-) AQM is turned on in all of our CMTSes (downstream queue) and in 
DOCSIS 3.1 modems (upstream queue).
>
> Have a nice weekend,
> Jason
>
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> 
https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!XLFMYPw-gnJgHzz_1nF-N7dNeIeT4QD-5wQny8vdAfYE6bzHtVQD3-lqiQI9YwCIw2ZGww$


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

[Bloat] Of interest: Comcast AQM Paper

[Livingood, Jason via Bloat]

 FYI that I will be presenting a lightning talk at the IRTF MAPRG meeting today 
at 17:30 ET 
(https://datatracker.ietf.org/meeting/111/materials/agenda-111-maprg). The talk 
links to a just-published paper at https://arxiv.org/abs/2107.13968 (click PDF 
link in upper right of page) that will likely be of interest to these two lists.

High-level: turning on AQM in the cable modem (upstream queue) took working 
latency from around 250 ms to between 15-30 ms, which is actually kind of cool. 
;-) AQM is turned on in all of our CMTSes (downstream queue) and in DOCSIS 3.1 
modems (upstream queue).

Have a nice weekend,
Jason

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

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

[Livingood, Jason via Bloat]

> 2) Users are pissed off, because they clicked on a web page, and got nothing 
> back. They retry on their screen, or they try another site. Meanwhile, the 
> underlying TCP connection remains there, pumping the network full of more 
> packets on that old path, which is still backed up with packets that haven't 
> been delivered that are sitting in queues.



Agree. I’ve experienced that as utilization of a network segment or supporting 
network systems (e.g. DNS) increases, you may see very small delay creep in - 
but not much as things are stable until they are *quite suddenly* not so. At 
that stability inflection point you immediately & dramatically fall off a 
cliff, which is then exacerbated by what you note here – user and machine-based 
retries/retransmissions that drives a huge increase in traffic. The solution 
has typically been throwing massive new capacity at it until the storm recedes.



> I should say that most operators, and especially ATT in this case, do not 
> measure end-to-end latency. Instead they use Little's Lemma to query routers 
> for their current throughput in bits per second, and calculate latency as if 
> Little's Lemma applied.



IMO network operators views/practices vary widely & have been evolving quite a 
bit in recent years. Yes, it used to be all about capacity utilization metrics 
but I think that is changing. In my day job, we run E2E latency tests (among 
others) to CPE and the distribution is a lot more instructive than the 
mean/median to continuously improving the network experience.



> And management responds, Hooray! Because utilization of 100% of their 
> hardware is their investors' metric of maximizing profits. The hardware they 
> are operating is fully utilized. No waste! And users are happy because no 
> packets have been dropped!



Well, I hope it wasn’t 100% utilization meant they were ‘green’ on their 
network KPIs. ;-) Ha. But I think you are correct that a network engineering 
team would have been measured by how well they kept ahead of utilization/demand 
& network capacity decisions driven in large part by utilization trends. In a 
lot of networks I suspect an informal rule of thumb arose that things got a 
little funny once p98 utilization got to around 94-95% of link capacity – so 
backup from there to figure out when you need to trigger automatic capacity 
augments to avoid that. While I do not think managing via utilization in that 
way is incorrect, ISTM it’s mostly being used as the measure is an indirect 
proxy for end user QoE. I think latency/delay is becoming seen to be as 
important certainly, if not a more direct proxy for end user QoE. This is all 
still evolving and I have to say is a super interesting & fun thing to work on. 
:-)



Jason












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

Re: [Bloat] Really getting 1G out of ISP?

[Livingood, Jason via Bloat]

> For DOCSIS the issue seems to be an unfortunate frequency split between up 
> and downstream and use of lower efficiency coding schemes.

Performance really takes a big step forward once a person has a D3.1 modem in 
their home, bringing OFDM and OFDMA as key advancements. Also in flux at the 
moment is where the upstream split is in cable networks, which are moving to 
mid-split or high-split designs that bring more upstream bandwidth. As well, 
over the past 18+ months, most cable networks have added substantially more 
upstream channels as well as performed quite a number of fiber node splits. And 
that is just below the physical layer stuff - there's also a lot of work at the 
software layer for modems and CMTSes that is quite interesting.

JL

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

Re: [Bloat] Really getting 1G out of ISP?

[Livingood, Jason via Bloat]

> It doesn't help that all the local ISP's claim 10Mbit upload even with 1G 
> download. Is this a head end provisioning problem or related to Docsis 3.0 
> (or later) modems?

I'll cover this in an upcoming technical paper (mid-July I hope). Depending on 
the DOCSIS version, CMTS, and cable modems involved you may have no AQM, or 
buffer controls for the cable modem, or AQM (sort of) on the CMTS and in the 
cable modem. In the Comcast network you should find AQM in the upstream queue 
on the cable modems for which we have deployed RDK-B software (XB6 and XB7), 
while other devices would have buffer controls.

JL

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

[Bloat] BITAG Paper Call for Contributors

[Livingood, Jason via Bloat]

Folks here may be interested… The BITAG (Broadband Internet Technical Advisory 
Group) is soon starting work on a paper explaining latency – targeted at 
policymakers, lawmakers, regulators, and other non-technical audiences.

These are papers that usually run 20 – 25 pages total and are produced via 
rough consensus. You can see previous papers at https://www.bitag.org/ -- but 
I’ll just note that the new / streamlined paper work rules have only been in 
effect since the last paper (2020 Pandemic Network Performance). There are 
usually many active contributors of text (so less burden on each person) and 
most work can be performed completely asynchronously (the draft doc is 
maintained in markdown on GitHub), with a bi-weekly coordination call.

Summary of the idea for the paper:
When people think of Internet performance it is typically solely in terms of 
speed. But when considering the end user quality of experience (QoE), latency 
is usually a key factor. Unfortunately, latency is not well understood in the 
policy or regulatory spheres or by the average consumer. This paper will 
explain and explore latency, including idle latency, latency under load, 
components of latency performance, how latency varies by access technology 
and/or protocol, and how latency can affect the user QoE for certain types of 
applications such as video conferencing, remote learning, gaming and more. As 
well, while the FCC MBA program reports on latency it takes no position on what 
is good or bad latency - a question this paper will explore. Additionally, this 
paper will examine metrics for characterizing latency performance, including 
various summary statistics for latency and latency variation (often referred to 
as "jitter"). Finally, the paper will look to the current state of the art and 
the future to explain Active Queue Management (AQM) and other low latency 
services - and the new types of applications that this may enable in the future.

If you might be interested, ping me & Doug Sicker (Exec Director of the BITAG, 
cc’d at dsic...@bitag.org) off-list.

Thanks
Jason



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

[Bloat] AQM & Net Neutrality

[Livingood, Jason via Bloat]

I’m looking for opinions here re bloat-busting techniques like AQM in the 
context of network neutrality (NN). The worry I have is whether some 
non-technical people will misunderstand how AQM works & conclude that 
implementing it may violate NN because it would make interactive traffic 
perform better than it does today. That is true of course – it’s a design goal 
of AQM, but non-interactive traffic performs as well as it always has – it is 
not disadvantaged.

Maybe the worries I have heard just points out the need for more 
education/awareness about what delay is and why things like AQM are not 
prioritization/QoS? I appreciate any thoughts.

Jason

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

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

[Livingood, Jason via Bloat]

Yes, he is the colleague to whom I referred. ;-) Anyway – appreciate all the 
input as I try out some new terminology on laypeople. So far working latency 
seems to be more comprehensible for folks but we shall see.

JL

From: Greg White 
Date: Tuesday, May 11, 2021 at 5:26 PM
To: Jonathan Foulkes , "Livingood, Jason" 

Cc: bloat 
Subject: [EXTERNAL] Re: [Bloat] Terminology for Laypeople

I recently heard Stuart Cheshire (sort of tongue-in-cheek) refer to “idle 
latency” as “the latency that users experience when they are not using their 
internet connection” (or something along those lines).

I think terminology that reinforces that the baseline (unloaded) latency is not 
always what users experience, and that latency under load is not referring to 
some unusual corner-case situation, is good.  So, I like “idle latency” and 
“working latency”.

-Greg



From: Bloat  on behalf of Jonathan Foulkes 

Date: Monday, May 10, 2021 at 2:10 PM
To: Jason Livingood 
Cc: bloat 
Subject: Re: [Bloat] Terminology for Laypeople

Hi Jason,

I’ve found that idle is a good descriptor for unloaded metrics, and for 
semi-technical audiences ‘working’ is a very good term. But for lay people, the 
term ‘loaded’ seems to work better, especially since we are talking about a 
metric that relates to capacity.

e.g.

When my truck is unloaded, my truck stops quickly, but when loaded, it takes 
longer to stop.

so now:

When my Internet line is unloaded, my latency is low, but when it is highly 
loaded (iCloud photo sync), the latency is very high.

Cheers,

Jonathan Foulkes




On May 4, 2021, at 8:02 PM, Livingood, Jason via Bloat 
mailto:bloat@lists.bufferbloat.net>> wrote:

Like many of you I have been immersed in buffer bloat discussions for many 
years, almost entirely within the technical community. Now that I am starting 
to explain latency & latency under load to internal non-technical folks, I have 
noticed some people don’t really understand “traditional” latency vs. latency 
under load (LUL).

As a result, I am planning to experiment in some upcoming briefings and call 
traditional latency “idle latency” – a measure of latency conducted on an 
otherwise idle connection. And then try calling LUL either “active latency” or 
perhaps “working latency” (suggested by an external colleague – can’t take 
credit for that one) – to try to communicate it is latency when the connection 
is experiencing normal usage.

Have any of you here faced similar challenges explaining this to non-technical 
audiences? Have you had any success with alternative terms? What do you think 
of these?

Thanks for any input,
Jason
___
Bloat mailing list
Bloat@lists.bufferbloat.net<mailto:Bloat@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/bloat<https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!SviWp1tUK05mhY86CJjmhVNVM210b56Lvk770IAgUQ_kIDOfyPAnlca8voyyYQP3Oi04yg$>

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

[Bloat] Terminology for Laypeople

[Livingood, Jason via Bloat]

Like many of you I have been immersed in buffer bloat discussions for many 
years, almost entirely within the technical community. Now that I am starting 
to explain latency & latency under load to internal non-technical folks, I have 
noticed some people don’t really understand “traditional” latency vs. latency 
under load (LUL).

As a result, I am planning to experiment in some upcoming briefings and call 
traditional latency “idle latency” – a measure of latency conducted on an 
otherwise idle connection. And then try calling LUL either “active latency” or 
perhaps “working latency” (suggested by an external colleague – can’t take 
credit for that one) – to try to communicate it is latency when the connection 
is experiencing normal usage.

Have any of you here faced similar challenges explaining this to non-technical 
audiences? Have you had any success with alternative terms? What do you think 
of these?

Thanks for any input,
Jason
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat