On Sun, 17 Mar 2019, Luca Muscariello wrote:
Fq_codel has an outstanding footprint in terms of deployment.
No, it doesn't.
A logical next step to me seems to push chipcos to build fq_codel in
silicon.
It is totally feasible.
... and how do you plan to make that happen?
--
Mikael
On Sun, 17 Mar 2019, Sebastian Moeller wrote:
All I’m trying to say is that this is bad engineering, apparently perpetuated
by bad transport layer implementations.
??? Now I am confuzed, to me engineering is all about balancing
trade-offs, and this is all about how to evaluate different
Luca Muscariello writes:
> 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
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.
Dear Carsten,
please excuse my tortured logic, being from outside the field it seems I
routinely misuse the nomenclature and sow confusion.
> On Mar 17, 2019, at 18:09, Carsten Bormann wrote:
>
>>>
> The end-to-end argument applies: Ultimately, there needs to be
> resequencing at
Vint -
BBR is the end-to-end control logic that adjusts the source rate to match the
share of the bolttleneck link it should use.
It depends on getting reliable current congestion information via packet drops
and/or ECN.
So the proposal by these guys (not the cable guys) is an attempt to
I helped land a more rfc - compliant version of pie into net-next late
last year.
ironically, we had one open bug re ecn -
https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2 -
docsis pie supported ecn not at all. I actually hold a good opinion of
pie - it is a good single queue aqm,
On Sun, 17 Mar 2019, Loganaden Velvindron wrote:
is there an open source implementation of PIE which is close to what is
used by the DOCSIS modems ?
PIE was added to the Linux kernel in 3.14 according to
https://www.linux.com/news/linux-314-release-no-pi-new-pie-fights-bufferbloat
--
On 17 March 2019 18:37:27 CET, Loganaden Velvindron wrote:
>On Sun, Mar 17, 2019 at 6:06 PM Mikael Abrahamsson
>wrote:
>>
>> On Sat, 16 Mar 2019, Holland, Jake wrote:
>>
>> > Granted, it still remains to be seen whether SCE in practice can
>match
>> > the results of L4S, and L4S was here
>>
The end-to-end argument applies: Ultimately, there needs to be
resequencing at the end anyway, so any reordering in the network would be
a performance optimization. It turns out that keeping packets lying
around in some buffer somewhere in the network just to do
Hi Carsten,
thanks for your insights.
> On Mar 17, 2019, at 15:34, Carsten Bormann wrote:
>
>>> The end-to-end argument applies: Ultimately, there needs to be
>>> resequencing at the end anyway, so any reordering in the network would be a
>>> performance optimization. It turns out that
>> The end-to-end argument applies: Ultimately, there needs to be resequencing
>> at the end anyway, so any reordering in the network would be a performance
>> optimization. It turns out that keeping packets lying around in some buffer
>> somewhere in the network just to do resequencing
On Sat, 16 Mar 2019, Holland, Jake wrote:
Granted, it still remains to be seen whether SCE in practice can match
the results of L4S, and L4S was here first. But it seems to me L4S comes
with some problems that have not yet been examined, and that are nicely
dodged by a SCE-based approach.
Hi Carsten,
> On Mar 17, 2019, at 11:23, Carsten Bormann wrote:
>
> On Mar 14, 2019, at 22:43, Sebastian Moeller wrote:
>>
>> if a specific link technology is prone to introduce reordering due to
>> retransmit it might as well try to clean up after itself
>
> The end-to-end argument
On Mar 14, 2019, at 22:43, Sebastian Moeller wrote:
>
> if a specific link technology is prone to introduce reordering due to
> retransmit it might as well try to clean up after itself
The end-to-end argument applies: Ultimately, there needs to be resequencing at
the end anyway, so any
15 matches
Mail list logo
