In revisiting this old thread, in light of this,
https://github.com/systemd/systemd/issues/9725
and my test results of cake with and without ecn under big loads... I
feel as though I'm becoming a
pariah in favor of queue length management, by dropping packets! In
bufferbloat.net! cake used to
as for the tail loss/rto problem, doesn't happen unless we are already
in a drop state for a queue, and it doesn't happen very often, and
when it does, it seems like a good idea to me to so thoroughly back
off in the face of so much congestion.
fq_codel originally never dropped the last packet in
"So there is no effect on other flows' latency, only subsequent
packets in the same flow - and the flow is always hurt by dropping
packets, rather than marking them."
Disagree. The flow being dropped from will reduce its rate in an rtt,
reducing the latency impact on other flows.
I regard an
Am 06.06.2018 um 10:15 schrieb Sebastian Moeller:
Well, sending a packet incurs serialization delay for all queued up packets, so
not sending a packet reduces the delay for all packets that are sent by exactly the
serialization delay. If egress bandwidth is precious (so when it is
> On Jun 6, 2018, at 09:44, Bless, Roland (TM) wrote:
>
> Hi,
>
> Am 05.06.2018 um 20:34 schrieb Sebastian Moeller:
>> The rationale for that decision still is valid, at low bandwidth every
>> opportunity to send a packet matters and every packet being transferred will
>> increase the
Hi,
Am 05.06.2018 um 20:34 schrieb Sebastian Moeller:
> The rationale for that decision still is valid, at low bandwidth every
> opportunity to send a packet matters and every packet being transferred will
> increase the queued packets delay by its serialization delay. The question
>
Hi Jonathan,
> On Jun 5, 2018, at 21:31, Jonathan Morton wrote:
>
>> On 5 Jun, 2018, at 9:34 pm, Sebastian Moeller wrote:
>>
>> The rationale for that decision still is valid, at low bandwidth every
>> opportunity to send a packet matters…
>
> Yes, which is why the DRR++ algorithm is used
> On 5 Jun, 2018, at 9:34 pm, Sebastian Moeller wrote:
>
> The rationale for that decision still is valid, at low bandwidth every
> opportunity to send a packet matters…
Yes, which is why the DRR++ algorithm is used to carefully choose which flow to
send a packet from.
> …and every packet
Hi Jonathan,
> On Jun 5, 2018, at 17:10, Jonathan Foulkes wrote:
>
> Jonathan, in the past the recommendation was for NOECN on egress if capacity
> <4Mbps. Is that still the case in light of this?
>
> Thanks,
>
> Jonathan Foulkes
>
>> On Jun 4, 2018, at 5:36 PM, Jonathan Morton wrote:
>>
> On 5 Jun, 2018, at 6:10 pm, Jonathan Foulkes wrote:
>
> Jonathan, in the past the recommendation was for NOECN on egress if capacity
> <4Mbps. Is that still the case in light of this?
I would always use ECN, no exceptions - unless the sender is using a TCP
congestion control algorithm that
10 matches
Mail list logo
