On Thu, Dec 9, 2021, 19:23 Sebastian Moeller wrote:
> Hi Luca,
>
>
> > On Dec 9, 2021, at 18:38, Luca Muscariello wrote:
> >
> > Hi Sebastian
> >
> > On Thu, Dec 9, 2021, 17:09 Sebastian Moeller wrote:
> > Hi Luca
> >
> &
Hi Sebastian
On Thu, Dec 9, 2021, 17:09 Sebastian Moeller wrote:
> Hi Luca
>
> > On Dec 3, 2021, at 15:58, Luca Muscariello wrote:
> >
> >
> >
> > On Fri, Dec 3, 2021 at 3:35 PM Sebastian Moeller
> wrote:
> > Hi Dave,
> >
> >
> &g
On Fri, Dec 3, 2021 at 3:35 PM Sebastian Moeller wrote:
> Hi Dave,
>
>
> > On Dec 3, 2021, at 15:18, Dave Taht wrote:
> >
> > On Fri, Dec 3, 2021 at 4:00 AM Luca Muscariello
> wrote:
> >>
> >> Test using a tp-link AP EAP 245
> >>
Test using a tp-link AP EAP 245
https://www.waveform.com/tools/bufferbloat?test-id=bbcc5ef5-e677-4f27-aa04-1849db81d0f5
On Thu, Dec 2, 2021 at 7:48 PM Dave Taht wrote:
> tp-link, is, so far as I know, the last major home router vendor NOT
> shipping a SQM system. Perhaps this could be modded
For those who might be interested in Little's law
there is a nice paper by John Little on the occasion
of the 50th anniversary of the result.
https://www.informs.org/Blogs/Operations-Research-Forum/Little-s-Law-as-Viewed-on-its-50th-Anniversary
https://www.informs.org/content/download/255808/241
atic binary.
>
> If anyone is interested would love to help them kick off a project. We
> can make it general enough to test Galene, Janus, Jitsi, Ion etc... If
> it gets acceptance from the greater WebRTC community it could really
> grow!
>
> [0] https://github.com/pion/rtsp-ben
Dave,
we have done extensive WebRTC (and several other online meeting
apps) testing lately and this paper
https://ieeexplore.ieee.org/document/9153228 reports a
methodology for WebRTC based on Chromium and Selenium Grid and
as test orchestrator Jitsi Torture.
I would avoid feeding clients with BB
Hi Erick,
one question about the PGW: is it a policer or a shaper that you have
installed?
Also, have you tried to run a ping session before and in parallel to the
curl sessions?
Luca
On Thu, Nov 19, 2020 at 2:15 PM wrote:
> Update:
> The 5G router was connected to a new base station. Now t
On Thu, Sep 3, 2020 at 4:32 PM Toke Høiland-Jørgensen wrote:
>
> Luca Muscariello writes:
>
> > On Thu, Sep 3, 2020 at 3:19 PM Mikael Abrahamsson via Bloat
> > wrote:
> >>
> >> On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote:
> >>
> >>
On Thu, Sep 3, 2020 at 3:19 PM Mikael Abrahamsson via Bloat
wrote:
>
> On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote:
>
> > Yup, the number of cores is only going to go up, so for CAKE to stay
> > relevant it'll need to be able to take advantage of this eventually :)
>
> https://www.hardkernel.
It is not surprising that BBR comes from Van who's also designed and
implemented pathchar.
I liked reading the paper when it was published and it has the merit to be
simple to read
for a large audience.
I agree very much on the title as bang-bang congestion control (not only
AIMD) could be
deprec
check video?
> placeholder
> > > and I may have misunderstood the part about video elasticity, but my
> > > interpretation at the time was that Stuart was claiming that video was
> > > elastic in that it would adjust downward to avoid overflowing a loaded
> > > link,
e to apply a circuit-breaker/policer in the network to
> perform admission control, but I don't see the link to L4S. Have I missed
> something ?
>
> Gorry
> On 28/04/2020 20:04, Luca Muscariello wrote:
>
> Hi Jake,
>
> Thanks for the notes. Very useful.
> The othe
it also will not go below a certain rate, and perhaps that quality can stay
> relatively good in spite of high network loss?
>
>
>
> Best regards,
>
> Jake
>
>
>
> *From: *Luca Muscariello
> *Date: *Tuesday, April 28, 2020 at 1:54 AM
> *To: *Dave Taht
> *Cc: *ts
Hi Dave and list members,
It was difficult to follow the discussion at the meeting yesterday.
Who said what in the first place.
There have been a lot of non-technical comments such as: this solution
is better than another in my opinion. "better" has often been used
as when evaluating the taste o
A Bloom filter based classifier for Bottlenecked vs non bottlenecked flows
was done in here in 2005.
https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf
And associated patent granted since 2011
https://patents.google.com/patent/US7933204B2/en?oq=US7933204B2+United+States++
Luca
On Thu, Jan 23,
On Thu, Oct 24, 2019 at 11:34 AM Toke Høiland-Jørgensen
wrote:
> Luca Muscariello writes:
>
> > On Wed, Oct 23, 2019 at 2:27 PM Toke Høiland-Jørgensen
> > wrote:
> >
> >> Rich Brown writes:
> >>
> >> >> On Oct 23, 2019, at 5:54 AM, >
On Wed, Oct 23, 2019 at 2:27 PM Toke Høiland-Jørgensen
wrote:
> Rich Brown writes:
>
> >> On Oct 23, 2019, at 5:54 AM, erik.tarald...@telenor.com>> wrote:
> >>
> >> If you could influence the 4G vendors to de-bloat their equipment,
> >> would you recommend BQL, L4S or codel/cake?
> >
> > I've be
On Sat, Aug 24, 2019 at 9:59 AM Sebastian Moeller wrote:
> Another nugget from the notes (
> http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/):
>
> This looks like an argument for fq_codel/cake's use of time instead of
> queue length, OR an argument for fq, because in a non-overwhelm
Remote attendance is free of charge but you have to register to be able to
access.
https://www.ietf.org/registration/ietf105/remotereg.py
On Wed, Jul 17, 2019 at 3:13 PM Dave Taht wrote:
> IETF 105 runs from July 20-27th in Montreal.
>
> https://datatracker.ietf.org/meeting/105/agenda/
>
> ts
Defs
https://tools.ietf.org/html/rfc2697
On Thu 11 Apr 2019 at 19:54, Jonathan Morton wrote:
> > On 11 Apr, 2019, at 1:38 pm, Mikael Abrahamsson
> wrote:
> >
> > The mbs defines the MBS for the PIR bucket and the cbs defines the CBS
> for the CIR bucket
>
> What do these lumps of jargon refer
the application.
If working from home, the quality of peering of an SP to cloud providers is
key.
I'd say that the Cloud and the decline of transit networks have facilitated
DSCP e2e.
On Sat, Mar 23, 2019 at 7:40 PM Mikael Abrahamsson wrote:
> On Sat, 23 Mar 2019, Luca Muscariel
WebEx, WebRTC they use it.
QoS works. To answer the question in the title of Michael’s paper.
It the app runs in the cloud and the cloud has direct peering links to your
branch office or SP
most likely DSCP works.
And going back to Roland’s proposal, it seems the most natural approach
instead of
+1
On Sat, Mar 23, 2019 at 9:02 AM Roland Bless wrote:
> Hi,
>
> On 22.03.19 at 19:28 Victor Hou wrote:
>
> > Broadcom has been deeply involved in developing the Low Latency DOCSIS
> > cable industry specification that Bob Briscoe mentioned. We concur with
> > the L4S use of ECT(1). L4S can be
To me there is substantial difference from something like fq_codel or
fq_pie where service differentiation is largely implicit
and approches largely based on explicit marking.
Approaches based on marking face technical and non technical challenges
that have been largely mentioned in these lists.
One of the two vikings, Toke, had the whole PhD thesis filled with
citations from Toy Story.
Not to mean that is less glorious... but...
On Tue, Feb 5, 2019 at 10:07 AM Toke Høiland-Jørgensen wrote:
> Dave Taht writes:
>
> > speaking of toke and jesper:
> >
> > "Two networking Vikings, masters
LOL!
On Thu 31 Jan 2019 at 15:07, Dave Taht wrote:
> https://twitter.com/yorksranter/status/1082601273315217408
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> ___
> Bloat mailing list
> Bloat@lists.bufferblo
I disagree on the claims that DC switches do not implement anything.
They do, from quite some time now.
https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html
On Thu, Dec 6, 2018 at 4:19 AM Dave Taht wrote:
> While I strongly agree wi
uild up process input > output, however
> this build up can e.g. happen in one RTT, while the standing queue can
> survive seconds or minutes (in reality, and indefinitely in theory).
> Though, I found that this correlation is often not modeled in
> queue-theoretical models.
>
>
AY TRADEOFF). For congestion control mechanisms
> that have steady state throughput of the kind R = f(d, p), for some
> function f, delay d and feedback p, if the feedback is based on purely
> end to end delay measurements, you can either have fairness or a fixed
> delay, but not both si
)
wrote:
> Hi Luca,
>
> Am 27.11.18 um 10:24 schrieb Luca Muscariello:
> > A congestion controlled protocol such as TCP or others, including QUIC,
> > LEDBAT and so on
> > need at least the BDP in the transmission queue to get full link
> > efficiency, i.e. the que
If you have multiple flows the BDP will change as measured at the end
points.
Also the queue occupancy has to accommodate the overshoot. If you have a
BDP in flight plus
epsilon you should not size based on the long term value but on the
overshoot.
If you don't have space for it, the long term valu
On Wed, Nov 28, 2018 at 11:40 AM Dave Taht wrote:
> On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello
> wrote:
> >
> > Dave,
> >
> > The single BDP inflight is a rule of thumb that does not account for
> fluctuations of the RTT.
> > And I am not talking ab
ts, as there's far more than BDP of
> discussion here, and what
> we need is sqrt(bdp) to deal with all the different conversational flows.
> :)
>
> On Tue, Nov 27, 2018 at 1:24 AM Luca Muscariello
> wrote:
> >
> > I think that this is a very good comment to the
summarize a table
> of the competing viewpoints, as there's far more than BDP of
> discussion here, and what
> we need is sqrt(bdp) to deal with all the different conversational flows.
> :)
>
> On Tue, Nov 27, 2018 at 1:24 AM Luca Muscariello
> wrote:
> >
> >
On Tue, Nov 27, 2018 at 2:49 PM Mikael Abrahamsson wrote:
> On Tue, 27 Nov 2018, Luca Muscariello wrote:
>
> > If you, Mikael don't want more than 10ms buffer, how do you achieve that?
>
> class class-default
>random-detect 10 ms 2000 ms
>
> That's
Another bit to this.
A router queue is supposed to serve packets no matter what is running at
the controlled end-point, BBR, Cubic or else.
So, delay-based congestion controller still get hurt in today Internet
unless they can get their portion of buffer at the line card.
FQ creates incentives for
paper.
On Tue 27 Nov 2018 at 12:53, Bless, Roland (TM)
wrote:
> Hi Luca,
>
> Am 27.11.18 um 12:01 schrieb Luca Muscariello:
> > A BDP is not a large buffer. I'm not unveiling a secret.
>
> That depends on speed and RTT (note that typically there are
> several flows wi
n Tue, 27 Nov 2018, Luca Muscariello wrote:
>
> > link fully utilized is defined as Q>0 unless you don't include the
> > packet currently being transmitted. I do, so the TXtteer is never idle.
> > But that's a detail.
>
> As someone who works with moving packet
at 11:35 AM Bless, Roland (TM)
wrote:
> Hi,
>
> Am 27.11.18 um 11:29 schrieb Luca Muscariello:
> > I have never said that you need to fill the buffer to the max size to
> > get full capacity, which is an absurdity.
>
> Yes, it's absurd, but that's what today&
)
wrote:
> Hi Luca,
>
> Am 27.11.18 um 10:24 schrieb Luca Muscariello:
> > A congestion controlled protocol such as TCP or others, including QUIC,
> > LEDBAT and so on
> > need at least the BDP in the transmission queue to get full link
> > efficiency, i.e. the queue n
I think that this is a very good comment to the discussion at the defense
about the comparison between
SFQ with longest queue drop and FQ_Codel.
A congestion controlled protocol such as TCP or others, including QUIC,
LEDBAT and so on
need at least the BDP in the transmission queue to get full link
On Fri 23 Nov 2018 at 18:27, Dave Taht wrote:
> On Fri, Nov 23, 2018 at 9:17 AM Luca Muscariello
> wrote:
> >
> > Yes there was some discussion about that.
> > Moving things to hardware should fix that.
> >
> > Evens traffic management in NPU based routers m
Yes there was some discussion about that.
Moving things to hardware should fix that.
Evens traffic management in NPU based routers makes use of hardware based
polling for shaping. These are trade offs one has to face all the time.
There has been a discussion at the defense about hardware vs softw
s,
> Bob
>
>
>
>
> On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello <
> luca.muscarie...@gmail.com> wrote:
>
>> Jonathan,
>>
>> Not that giant handwaving though.
>> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The
Jonathan,
Not that giant handwaving though.
IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The almost
is necessary as it operates in 2.4/5Ghz bands.
Similar to what you describe, and is coming very soon in shipping products.
RTS/CTS is still a LBT to create a window where TDM can
and C) you can implement any packet scheduler using a timing wheel using
virtual times.
On Fri, Jul 20, 2018 at 4:09 PM Dave Taht wrote:
>
> https://www.files.netdevconf.org/d/46def75c2ef345809bbe/files/?p=/Evolving%20from%20AFAP%20%E2%80%93%20Teaching%20NICs%20about%20time.pdf
>
> Talking about
Good point. Flow isolation gives some kind of “privacy”.
But I guess this is not the worse privacy violation one would be concerned
about in today Internet.
On Thu 19 Jul 2018 at 12:52, Dave Taht wrote:
> hahaha. Aside from their last slide not recommending fq, that was an
> enjoyable read. fq
I'm aware of this one. The last time I checked Linux patches seemed to be
abandoned.
Hit ratio could be v v low if you remove UDP encap. Look at IPSEC.
On Wed, Apr 4, 2018 at 12:52 PM, Mikael Abrahamsson
wrote:
> On Wed, 4 Apr 2018, Luca Muscariello wrote:
>
> And yes,
I'm looking at TAPS too as I'm looking for a general transport API other
than TCP/UDP.
The kind of transport services we have developed in here
https://git.fd.io/cicn/ do not fit in the current API.
Full user land implementation, which seems to be accepted nowadays, but not
at all a few years back
Next challenge: FQ into silicon...
One of the reasons of what Jim describes under the "Here lies madness"
section
is related to silicon built-in functionalities and the ability to update
software in edge-routers.
Many chipcos build their board with several CPU offloading mechanisms,
e.g.
to supp
If I understand the patch well, the ack filter is actually fixing the
problem of ACK compression only.
Because it is enforced on packets in the queue only. It is stateless.
ACK compression would happen even w/o highly asymmetric access links by
just
having concurrent data streams with ack streams.
ncy exceeds a small number.
>
>
>
> Typical operating points of corporate networks where the users are happy
> are single-digit percentage of max load.
>
>
>
> This is also true of computer buses and memory controllers and storage
> interfaces IRL. Again, latency is the pri
I think everything is about response time, even throughput.
If we compare the time to transmit a single packet from A to B, including
propagation delay, transmission delay and queuing delay,
to the time to move a much larger amount of data from A to B we use
throughput in this second case because
https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html
On Fri 1 Dec 2017 at 19:43, Dave Taht wrote:
> Luca Muscariello writes:
>
> > For highly asymmetric links, but also shared media like wifi, QUIC might
> be a
> >
I think only IPSEC would be a problem for fastACK but not TLS.
On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин wrote:
> As I noticed from the Meraki document:
>
> "FastACK also relies on packet inspection, and will not work when
> payload is encrypted. However, in our networks, we do not currentl
If I understand the text right, FastACK runs in the AP and generates an ACK
on behalf (or despite) of the TCP client end.
Then, it decimates dupACKs.
This means that there is a stateful connection tracker in the AP. Not so
simple.
It's almost, not entirely though, a TCP proxy doing Split TCP.
On
For highly asymmetric links, but also shared media like wifi, QUIC might be
a better playground for optimisations.
Not pervasive as TCP though and maybe off topic in this thread.
If the downlink is what one want to optimise, using FEC in the downstream,
in conjunction with flow control could be ve
Agree and think this is a lucid analysis of the problem(s) and solution(s).
But, what can be done to let clients upgrade orders of magnitude faster
than today?
Move transport in user space inside the app? Else?
On Thu, Nov 30, 2017 at 8:48 AM, Jonathan Morton
wrote:
> I do see your arguments
On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson
wrote:
> On Wed, 29 Nov 2017, Luca Muscariello wrote:
>
> Why does it say to do this? What benefit is there to either end system to
>>> send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP
>>> transfer?
Did you check RFC 3449 ?
https://tools.ietf.org/html/rfc3449#section-5.2.1
It would be interesting to know what is the minimum ACK rate to achieve
full utilisation.
Or the how the downlink rate depends on the uplink ACK rate.
I'm sure I've seen this dependency in some old paper.
On Wed, Nov 29,
Dave,
If the objective is to run experiments with some emulated wifi I could
suggest
a workaround that we are using. It is not based on qdisc only.
It is based on ns3 emulation and linux bridges.
https://git.fd.io/cicn/tree/emu-radio/README.md?h=vicn/master
The radio emulation piece includes 80
Air time fairness has a strong theoretical foundation.
So I should cite Newton and say that Toke is sitting on giants' schoulders
:)
In multi rate systems in a shared channel, time is the right resource to
share.
Then one could discuss about which fairness criterion to use, but that's
secondary.
Le 25/09/2013 17:15, Eric Dumazet a écrit :
On Tue, 2013-09-24 at 14:25 +0200, James Roberts wrote:
No one responded to Luca's Sept 1 comment (on the bloat list) that the
new code seems to do tail drop rather than longest queue drop.
If this is so, bandwidth sharing will not be fair since FQ a
64 matches
Mail list logo