> quic takes over
Now if only thay had gotten the layering right... such a terrible wasted
opportunity.
(SCTP forever!)
-- Juliusz
___
LibreQoS mailing list
LibreQoS@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
I do not have a good answer anymore. My guess is blocking ipv6 tcp
port 443 and leaving udp port 443 open would work due to quic choosing
a lower packet size in general, and thus no pmtu needed.
On Thu, Mar 14, 2024 at 1:38 PM David Lang wrote:
>
> we are having some issues with ipv6, since you
If MTU discovery fails it's usually because a device is trying to
seamlessly fragment. Set do not fragment on your device nearest the
customer and that should solve it.
On Thu, Mar 14, 2024 at 11:38 AM David Lang via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:
> we are having some issues
we are having some issues with ipv6, since you are a big ipv6 advocate, you may
be able to help
we get IPv6 via a hurricane electric tunnel and apparently PMTU discovery is
misbehving. We've tried reducing the MTU a bit but still having issues.
David Lang
On Thu, 14 Mar 2024, David Lang via
On Thu, 14 Mar 2024, Dave Taht via Make-wifi-fast wrote:
I am curious if anyone here is at scale this week? (it is in pasadena, and
one of my favorite conferences - https://www.socallinuxexpo.org/scale/21x )
One of our core bufferbloat contributors (david lang) used to fq_codel the
wifi there
quic takes over
-- Forwarded message -
From: Xin Long
Date: Mon, Mar 11, 2024 at 12:23 PM
Subject: [RFC PATCH net-next 0/5] net: In-kernel QUIC implementation
with Userspace handshake
To: network dev
Cc: , , Eric Dumazet
, Paolo Abeni , Steve French
, Namjae Jeon , Chuck Lever
I am curious if anyone here is at scale this week? (it is in pasadena, and
one of my favorite conferences - https://www.socallinuxexpo.org/scale/21x )
One of our core bufferbloat contributors (david lang) used to fq_codel the
wifi there and they built custom boxes to manage the wifi in general
