Hi Matt and Jamshid,
On 04.07.20 at 19:29 Matt Mathis via Bloat wrote:
> Key takeaway: pacing is inevitable, because it saves large content
> providers money (more efficient use of the most expensive silicon in
> the data center, the switch buffer memory), however to use pacing we
> walk away
Hi Jonathan.
On 11.06.20 at 18:14 Jonathan Morton wrote:
>> On 11 Jun, 2020, at 7:03 pm, David P. Reed wrote:
>>
>> So, what do you think the latency (including bloat in the satellites) will
>> be? My guess is > 2000 msec, based on the experience with Apple on ATT
>> Wireless back when it was
Hi Dave,
On 19.03.20 at 23:12 Dave Taht wrote:
> This git repository seems to have codel and pie in it for dpdk
and also GSP.
> https://git.scc.kit.edu/TM/DPDK_AQM_Switch
>
> That appears to have not been upstreamed into the main dpdk repo. Does
> anyone know of a later/greater version?
No,
Hi Dave,
On 30.05.19 at 15:38 Dave Taht wrote:
> On Thu, May 30, 2019 at 4:31 AM Roland Bless wrote:
>>
>> Hi Dave,
>>
>> On 29.05.19 at 17:05 Dave Taht wrote:
>>> I have been trying to work through this paper:
>>> https://arxiv.org/pdf/1903.03852.pdf
Hi Dave,
On 29.05.19 at 17:05 Dave Taht wrote:
> I have been trying to work through this paper:
> https://arxiv.org/pdf/1903.03852.pdf
> which is enormous and well worth reading.
>
> I have a theory, though, about TABLE XII, which contrasts four BBR
> flows at different RTTs, in that BBRv1's
Hi Michael,
thanks for the pointer. Looking forward to the talk...
Regards
Roland
On 23.03.19 at 18:48 Michael Welzl wrote:
> Hi,
>
> I’ll do what academics do and add our own data point, below:
>
>> On Mar 23, 2019, at 4:19 PM, Roland Bless > <mailto:roland.bl...@k
Hi Jonathan,
On 23.03.19 at 16:03 Jonathan Morton wrote:
>> On 23 Mar, 2019, at 11:02 am, Mikael Abrahamsson wrote:
>>
>> On Sat, 23 Mar 2019, Roland Bless wrote:
>>
>>> I suggest to use an additional DSCP to mark L4S packets.
>>
>> DSCP doesn't wo
Hi Mikael,
On 23.03.19 at 18:16 Mikael Abrahamsson wrote:
> On Sat, 23 Mar 2019, Roland Bless wrote:
>
>> It's true that DSCPs may be remarked, but RFC 2474
>> already stated
>>
>> Packets received with an unrecognized codepoint SHOULD be forwarded
>> as
Hi Mikael,
On 23.03.19 at 11:02 Mikael Abrahamsson wrote:
> On Sat, 23 Mar 2019, Roland Bless wrote:
>
>> I suggest to use an additional DSCP to mark L4S packets.
>
> DSCP doesn't work end-to-end on the Internet, so what you're suggesting
> isn't a workable solution.
It'
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 implemented either in a dual-queue or
> an fq implementation. SCE
Hi,
On 27.11.18 at 23:19 Luca Muscariello wrote:
> I suggest re-reading this
>
> https://queue.acm.org/detail.cfm?id=3022184
Probably not without this afterwards:
https://ieeexplore.ieee.org/document/8117540
(especially sections II and III).
Regards,
Roland
Hi Kathie,
[long time, no see :-)]
I'm well aware of the CoDel paper and it really does a nice job
of explaining the good queue and bad queue properties. What we
found is that loss-based TCP CCs systematically build standing
queues. Their positive function is to keep up the link utilization,
Hi Dave,
On 11.05.2011 05:32, Dave Taht wrote:
1) in a wireshark analysis, the %interface part is lost
But your wireshark is listening on some specific interface,
isn't it? This interface is your context then and link locals are
unique on that particular link (which is assured by
Duplicate
Hi Dave,
On 09.05.2011 05:26, Dave Taht wrote:
I am modestly stumped as to how to solve this properly. I think it's
been causing problems with ipv6 for a long time, but I could be wrong.
see http://www.bufferbloat.net/issues/126
Basically although the underlying interfaces do have unique
14 matches
Mail list logo
