On Thu, May 16, 2024 at 12:55:38PM +0200, Ondrej Zajicek wrote:
> Yeah, i think that using TCP_NODELAY for BGP makes sense, considering
> there is already non-trivial framing and we write individual BGP
> messages with one write().
I suspect it might be better for throughput to send multiple BGP
m
Hello Douglas,
just a really fast response, we aren't going to implement BGP over QUIC
at all, at least when TLS is a required part of QUIC.
There are some thoughts about BGP 5 being encoded as CBOR and sent over
something like QUIC, anyway it doesn't make any sense to introduce QUIC
to BGP now.
I'm not a programmer, and I know almost nothing about it...
But reading this thread, I remembered this draft about BGP-over-QUIC.
https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/
I'm not sure what I'm going to say, but I have the impression that the
session closure control method that
send(..., MSG_MORE)
send(..., 0)
Is roughly equivalent to
setsockopt(..., TCP_CORK, 1)
send(..., 0)
send(..., 0)
setsockopt(..., TCP_CORK, 0)
In cases where you know that you're going to write more but you want to be able
to discard the user space buffer, MSG_MORE is useful. If holding onto the
On Wed, May 15, 2024 at 06:37:18PM +0200, Job Snijders via Bird-users wrote:
> Dear BIRD people,
>
> On most systems RFC 896 TCP congestion control is used, also known as
> "Nagle's algorithm". This algorithm is intended to help coalesce
> consecutive small packets from userland applications (like
