> I don't know if JSON serialization is deterministic, but I know a couple
> of cases when it is not.
> If the type or some type inside it has a custom JSON marshaller (method
> MarshalJSON), then if that function's output is not deterministic, the
> whole JSON for the type is not deterministic.
Hi,
Suppose that I call json.Marshal on two structures that are deep equal,
or on the same structure at different times. Are the outputs guaranteed
to be bytewise identical?
(The reason I'm asking is that I'm sending JSON over HTTP, and I need to
know whether it is correct to send a strong ETag
>> There should be a knob in the kernel to transparently replace TCP with
>> MP-TCP, but I couldn't find one.
> There is, sorta. Specifically, a BPF hook that can override the protocol
> (added in kernel 6.6):
>
> https://lore.kernel.org/all/cover.1692147782.git.geliang.t...@suse.com/
So we're
Hi,
For those of you who don't remember, MP-TCP is an extension to TCP that
implements multipath, and can be used both for fast roaming (redundancy)
and for bandwidth aggregation. MP-TCP is able to cross NATs, and it can
reliably detect that TCP extensions are being corrupted by middleboxes and
Thanks for your reply, Colin.
> While I realize that this doesn't introduce a new external dependency, I
> have to say that this is not the week to be asking for a new distro
> patch to OpenSSH!
Point taken.
> I'd be happy to include this if upstream does, but I don't think I'm
> likely to
Thanks for your reply, Colin.
> While I realize that this doesn't introduce a new external dependency, I
> have to say that this is not the week to be asking for a new distro
> patch to OpenSSH!
Point taken.
> I'd be happy to include this if upstream does, but I don't think I'm
> likely to
compatible with
existing clients and servers. It solves the main issue that causes people
to prefer mosh to ssh.
Thanks,
-- Juliusz Chroboczek
compatible with
existing clients and servers. It solves the main issue that causes people
to prefer mosh to ssh.
Thanks,
-- Juliusz Chroboczek
> Just working around [...] babeld's non-atomic route replacement interacting
> badly with BIRD's proto/radv.
I guess we could revive atomic updates in babeld, perhaps the buggy
kernels it didn't work with are no longer relevant.
> *neighbour table*. I think the crux of the issue I was seeing is
> Just working around [...] babeld's non-atomic route replacement interacting
> badly with BIRD's proto/radv.
I guess we could revive atomic updates in babeld, perhaps the buggy
kernels it didn't work with are no longer relevant.
> *neighbour table*. I think the crux of the issue I was seeing is
> I've just come across a reason I'd want to run babel with both bird and
> babeld on the same node and have them become neighbours.
I hope you know what you're doing.
The simplest solution would be to run each daemon in a different container.
If you don't want to use containers, you'll want to
> I've just come across a reason I'd want to run babel with both bird and
> babeld on the same node and have them become neighbours.
I hope you know what you're doing.
The simplest solution would be to run each daemon in a different container.
If you don't want to use containers, you'll want to
> I don't think it's a violation of the Babel protocol to use IPv6 next hops
> when
> an IPv4 address is present.
Yes, it's legal, but discouraged. Please see RFC 9229 Section 2.1:
If the outgoing interface has been assigned an IPv4 address, then, in
the interest of maximising
> quic takes over
Now if only thay had gotten the layering right... such a terrible wasted
opportunity.
(SCTP forever!)
-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
> 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
> 1) Is there any advice you could offer for rtt cost/min/max/decay values when
> using Bird2 ?
1. RTT-MIN
In the ideal case, your network consists of a number of interconnected
clusters. For example, if you have routers in Berlin, Paris and Warsaw,
then each of the cities constitutes a
> Babeld does have (most of) the knobs I think you'd need but it's just not
> suitable for 24/7 operation outside of toy networks without major rework
> (sorry Juliusz!).
No need to apologise. Babeld is the work of dozens of interns over ten
years. I've done some work to clean up the code, but
Hello Pim,
> I finished a few small code changes in VPP to allow transit-net-less transport
> of IPv4 and IPv6 in VPP and wrote about it on
> https://ipng.ch/s/articles/2024/03/06/vpp-babel-1.html. Considering this
> dataplane has some different idioms than Linux, it took a bit of work.
First of
>> I'm not sure how that could happen at boot time, it would need to
>> happen whenever a DHCPv4 lease changes. This implies that the router
>> might need to renumber if the ISP changes its allocation, and there are
>> no renumbering procedures for IPv4 (I'm not sure if anyone implements
>> RFC
> But my point is that the OpenWrt router has no way to predict what
> address/subnet will be assigned to its WAN port.
In principle, the ISP should assign either a global address, or an address in
the range 100.64.0.0/10 (RFC 6598). This range was deliberately chosen to
not collide with RFC
Package: gopls
Version: 1:0.16.1+ds-1
Severity: wishlist
Hi,
It would appear that the versions of the gopls package version do not
correspond to upstream versions.
At the time of writing, the versions in Debian are
* unstable: 1:0.17.0+ds-1
* testing: 1:0.16.1+ds-1
On the other hand, the
> As an alternative suggestion, I have since evaluated babel which mostly
> suits my purposes (except for some features not yet implemented in bird,
> like strict bind)
Could you please explain what's the feature you're missing?
Thanks,
-- Juliusz
> I never met him.
Neither have I.
> I was so pleased his algorithms held up all these years and found new
> use cases, as they did in babel.
Please read this in his memory:
Mills, D.L. (August 1988). The Fuzzball (PDF). ACM SIGCOMM 88
Symposium. Palo Alto, CA. pp. 115–122.
> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).
There's quite a few good ideas in this draft, but the one that I find
intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than
milliseconds.
I wonder how well this works. I'll experiment with undergrads.
--
> Apparently wine 9.0 rc2 includes bcryptprimitives.dll now (I tested on it
> and it did work).
Thanks for the hint, it apparently works with 8.19 (wine-development in
Debian).
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
> Apparently the change below broke Windows apps when running under Wine as
> it made bcryptprimitives.dll a hard requirement now and this dll is not
> bundled with Wine. This is true even for programs that do not use it all
> (like a simple "hello world" program).
>
>
> Is tying source address filtering to the routing table the right thing to do
> here? It seems to me that it would cause issues similar to those we see more
> generally with Unicast Reverse Path Filtering
Issues are caused by the kernel performing filtering that the routing
protocol is not aware
> Is tying source address filtering to the routing table the right thing to do
> here? It seems to me that it would cause issues similar to those we see more
> generally with Unicast Reverse Path Filtering
Issues are caused by the kernel performing filtering that the routing
protocol is not aware
>> And babeld the reference implementation also allows enabling link quality
>> estimation and the RTT extension at the same time, matching the current
>> behavior of bird.
Exactly right.
> Considering that ETX estimates number of retransmissions, then for
> algorithm that takes into account
--- Begin Message ---
On 2023-10-31 16:14, Maria Matejka via Bird-users wrote:
if you wish to meet us, please let us know preferably during this week
and we may do some BIRD meetup.
… we decided on Tuesday evening, beginning around 19:00, in some pub
nearby. The exact location is still TBD.
--- Begin Message ---
Hello!
Just a short reminder for those attending IETF 118 – we aren't
officially attending, anyway, if you wish to meet us, please let us know
preferably during this week and we may do some BIRD meetup.
Have a nice journey to Prague and remember, we have the 2nd best[1]
> default type tunnel rtt-min 1 rtt-max 1001 max-rtt-penalty 1000
> enable-timestamps true
> ```
> It causes the RTT to be equal to the latency to the other node.
More precisely, it causes the cost to be equal to the RTT.
The recommended default values are much more conservative:
rtt-min 10
It looks like the RTT metric was released as part of BIRD 2.14.
Congratulations, Toke!
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Thanks for your review, Roni.
> The document was changed in 02 from experimental to standard track. There is
> text in the end of section 4 about the algorithm being experimental
Right.
> from the mailing list i noticed that the reason to make it standard
> track is to allow using the TLVs by
> If I understand correctly, galene would support p2p media streams?
No, Galene only does client-server media. Before I wrote Galene,
I experimented with peer-to-peer WebRTC, and it worked beautifully in
small groups, but collapsed somewhere around 4 to 5 participants.
The problem is not the
> what apps do you have on the phone and what are they configured to update?
> that will make a huge difference.
It's not about my phone, it's about that of the author of the blog.
> 'idle' probably isn't nearly as passive as you think it is.
My personal phone is almost completely idle when I'm
> what apps do you have on the phone and what are they configured to update?
> that will make a huge difference.
It's not about my phone, it's about that of the author of the blog.
> 'idle' probably isn't nearly as passive as you think it is.
My personal phone is almost completely idle when I'm
> Admittedly, I was using galene.org
Full credit where credit is due: the congestion controller in the
downstream direction lives in the browser, so full credit to the folks
behind libwebrtc. As to the upstream direction, we're using our homebrew
code, which is not very good.
We're currently
Hi Dave!
> https://nickvsnetworking.com/mobile-ipv6-tax/
« This means my Android phone consumes 4.5 MB of cellular data in an hour
while sitting on the desk, with 16,889 packets in/out. »
So even discounting the headers, the phone receives 70 Commodore C64 worth
of data when idle. Every
Hi Dave!
> https://nickvsnetworking.com/mobile-ipv6-tax/
« This means my Android phone consumes 4.5 MB of cellular data in an hour
while sitting on the desk, with 16,889 packets in/out. »
So even discounting the headers, the phone receives 70 Commodore C64 worth
of data when idle. Every
Daniel, Kyle,
I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer. Is
it because interfaces are expensive in the Linux kernel? Or is there some
other reason why it is better to run all WG tunnels over a
Daniel, Kyle,
I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer. Is
it because interfaces are expensive in the Linux kernel? Or is there some
other reason why it is better to run all WG tunnels over a
> CONNECT-UDP
Come on, David, we all know that MASQUE is an elaborate practical joke.
With draft-asedeno-masque-connect-ethernet, you guys are obviously trying
to see how far you can go before people realise you're taking the piss.
> (You could even perform dichotomy there to measure the exact
Hi,
Babeld 1.13.1 is available from
https://www.irif.fr/~jch/software/files/babeld-1.13.1.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.13.1.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
This version
> While you're absolutely right that this MUST NOT happen, in practice it does.
I think we're in at least partial agreement. The point I'm making is that
this configuration is not something that's supported by IP, and that VPN
implementations that cause MTU blackholes are quite simply buggy.
> Uups, nevermind this. I was looking at the other node's hellos. The
> neighbour relationship goes down properly as you'd expect.
Merged into master. Shall I release 13.1?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I can observe (some) hellos using the padding depending on the option
> setting. Problem is when I force the interface MTU to 1280 instead of the
> initial 1420 the padded hellos get dropped and don't reach the other side
> as you'd expect, but the regular sized hellos still make it through and
Daniel,
Could you please test the new branch "probe-mtu"? It's now using the
IPV6_DONTFRAG cmsg in sendmsg, so it's enough to say
default probe-mtu true
(No global options, only per-interface options.)
-- Juliusz
___
Babel-users mailing list
> To test dont-fragment I first set it to disabled and changed the
> (wireguard) interface MTU from 1420 to 1280 at runtime. Doing this I can
> observe babel hellos being fragmented in tcpdump.
>
> When setting dont-fragment true this trick doesn't work and the neighbour
> relationship to the
Completely untested. Please checkout the branch "probe-mtu", then say
this in your config file:
dont-fragment true
default probe-mtu true
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> RFC 2460: "link MTU - the maximum transmission unit, i.e., maximum packet
>>size in octets, that can be conveyed over a link."
> I read this as "link MTU" being the maximum packet size that you could ever
> hope to be able send but the link technology could very well not allow the
>> Sorry, I wasn't clear. IP requires every link to have a well-defined
>> MTU: all the nodes connected to a link must agree on the link's MTU.
> I don't think that can be true either. PMTU can vary and paths can be
> asymmetric so two nodes could very well see different MTUs across the
>
>> IP does not support variable MTU links.
>
> Excuse me, but that's plain false. IP was designed in an environment where
> (non-ethernet) networks with various MTU standards were commonplace
Sorry, I wasn't clear. IP requires every link to have a well-defined
MTU: all the nodes connected to a
> Problem is when the underlay L3 network is composed of more tunnels and not
> 1500 MTU ethernet links, then at each hop the path MTU could be reduced by
> the tunnel overhead again and again and again (across the entire
> path). Hence no predictable MTU I can deploy across all my interfaces
>
> I've been running babel on top of my wireguard IPv6 network for a while now
> and I have a problem that keeps biting me and I can't find a good solution
> for: babel is oblivious to a link's MTU and picks paths that involve
> wireguard-in-wireguard tunnels even though paths without this stacking
Hi,
Babeld 1.13 is available from
https://www.irif.fr/~jch/software/files/babeld-1.13.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.13.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
This version updates
> + link quality
> + If set, link quality estimation is performed on this interface.
There are multiple algorithms for estimating link quality, and the one
currently implemented by BIRD is ETX. Hence, I feel that this should not
be a mere switch, but a selector with possible values
> You basically shouldn't do it. BIRD does something like last-resort pointer
> comparison and we should probably even add a warning if somebody misconfigures
> in this way.
Why not use the protocol's default preference as a last-resort tie-breaker?
It's probably less code than the warning you
> The only corner of the babel RFC that still scares me are "sources" :)
Then let me lecture a bit :-)
Babel is partly based on the ideas in DSDV, which was a pure mesh
protocol. In DSDV, there is no distinction between prefix, neighbour and
source: the IP address of a router is used as the
> A couple of days ago, I started to work on implementation of the Babel
> protocol in Go driven by the following objectives:
Excellent news. Babel is a protocol, and I'm trying to encourage
independent implementations of the protocol. In fact, I consider that the
implementation in BIRD is
> One place where things fall down also is in ECMP, (which babel does
> not do presently?)
It does not.
ECMP improves throughput in some cases, but unless done very carefully it
tends to improve latency (the effective latency of the aggregated link
tends to be higher than the latencies of either
Hi David!
> Unfortunately there just doesn't seem to be enough interest from the FRR
> community; it's kinda understandable considering FRR has gotten rather
> datacenter heavy.
Where did the cool people go? BIRD or proprietary routers?
> If someone is interested (and can spare some of that
> Out of interest: Is there a reason why FRR doesn't just use babeld, but
> something of its own?
Babeld works by speaking directly to the kernel. If multiple routing
protocols are running, they all manipulate the kernel's routing table,
which requires them to collaborate in order to decide
> https://blog.vyos.io/vyos-project-april-2023-update
That sounds like good news, but unfortunately, it appears to be based on
the FRR version of Babel, which is old and buggy.
https://github.com/FRRouting/frr/issues/11390
https://github.com/FRRouting/frr/issues/13337
-- Juliusz
> in the LuCi interface of OpenWrt the `Hello-Reach` is displayed as a
> decimal number. However, in babeld's local configuration interface it
> is displayed as a hexadecimal number. Which representation is the
> "correct" one or is there a "correct" one at all?
It's a sequence of 16 booleans.
> babeld-format:
> default hello-interval 4
> default type tunnel rtt-min 1 rtt-max 1001 max-rtt-penalty 1000
> enable-timestamps true
>
> generated from uci:
> default hello-interval 4
> default type tunnel
> default rtt-min 1
> default rtt-max 1001
> default max-rtt-penalty 1000
> default
Hi,
I've just merged optimised route redistribution into master. I've done
some testing, but I'm sure there are bugs left.
Please test.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> There is one gotcha that I'd like to point out. babeld fucks with a number
> of ip sysctls which you might not expect if your routers are already setup
> as you want them. You can disable this using `skip-kernel-setup true`. Grep
> the source for skip_kernel_setup to see the sysctls it touches.
> The field sin6_scope_id should be used only for link-local addresses (to
> define their scope), not as a way to route multicasts.
>
> (Hmm, ff02::/16 is defined as link-local multicast address, so perhaps
> setting sin6_scope_id makes sense.)
FWIW, babeld uses the sin6_scope_id when sending
> I would approach the stability problem from an electronics/signal
> processing/control theory background.
I have no signal processing background whatsoever; to my eyes, signal
processing is a fairly advanced for of magic. (My background is in logic
and programming languages.)
> Frankly I
Hi Daniel,
> In order to prevent RTT based routing from causing persistent traffic
> oscillations we delay core rte announcement of each prefix by a
> configurable but metric invariant amount of time.
Could you please explain how that works? How does it interact with
cost smoothing and route
>> (There's also the PMTUD problem described in RFC 9229 Section 3.)
> Juliusz, do you, or any one else, have info on:
> How does ${vendor} behave when reverse path filters are enabled?
I was under the impression that some kinds of ICMP pakets are not subject
to RPF. See RFC 4890 Section 4.3.1.
> I don't really have a particular use case in mind for exposing the
> metric, as indicated by my comment above. It just occurred to me as
> something that *might* be useful for someone :)
I certainly emphatise with your instinct to export as many useful knobs as
possible. However, just like
> My thinking was that filters may want to do something like:
>
> if (metric == smoothed_metric)
> metric += 100; /* route is stable, we can apply our policy */
>
> but I honestly don't know if that's useful for anything in reality :)
I'm a little conflicted on this. On the one hand, it's
>> Agreed. https://www.rfc-editor.org/how-to-report/
> Done :)
Perfect, thanks a lot.
>> Agreed. https://www.rfc-editor.org/how-to-report/
> Done :)
Perfect, thanks a lot.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> That's a bug in the new RFC text then ;)
Agreed. https://www.rfc-editor.org/how-to-report/
-- Juliusz
> That's a bug in the new RFC text then ;)
Agreed. https://www.rfc-editor.org/how-to-report/
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> I don't think RFC8966 is really framed in bird's "multi protocol" mindset
See the beginning of Section 3.7, which describes how a route
redistributed from another protocol has router-id set to the local
router's id. Babel updates for the same prefix are processed as usual,
with the routes
> I don't think RFC8966 is really framed in bird's "multi protocol" mindset
See the beginning of Section 3.7, which describes how a route
redistributed from another protocol has router-id set to the local
router's id. Babel updates for the same prefix are processed as usual,
with the routes
>> Of course, if there are no feasible routes to a given destination, then
>> the neighbours will perform an end-to-end search for a loop-free route,
>> but that's the neghbours' problem, not ours.
> I can't say I agree with the "their problem" mentality. The way I see it
> during graceful
> I think I figured out whats going on: babeld immediately flushes the kernel
> routes it installed when shutting down, without waiting for neighbours to
> switch to a different path.
Right. How long is the disruption?
> I figure this has to be configurable option since full propagation of the
> I think the answer should be that no matter how you mess with the metrics
> babel should still remain loop-free, right?
Both Babel and BGP should remain loop-free whatever you do. However, when
you redistribute routes between protocols, there's no guarantee that the
union of the two graphs
> Hence my question some time ago at the Mailling list if there is some
> kind of "include" statement in babeld.
You may use multiple '-c' options on the command-line to include multiple
configuration files. There's no include statement currently, but I could
certainly add one.
> I guess it would also help if babel could send some kind of metadata along
> with the routes. Like BGP communities or some such. Has this been thought
> about already?
No objection, but there are a few questions we'd need to answer first:
1. Should the metadata be mandatory or not? Suppose
https://mk16.de/blog/the-crxn-dn42-interconnection-is-up/
Interestingly, the two networks use overlapping prefixes, which requires
enumerating hundreds of prefixes in their filters. This is a case where
BIRD's support for Babel is likely to be useful: babeld's filtering
engine is simply not
Hi,
Discussions related to Babel are currently distributed across three
distrinct mailing-lists (babel-users@alioth, babel@ietf, bird-users), and
I'm a little concerned that those of you who are subscribed to just one of
them are missing out on the whole picture. Since I'm on strike today, and
Hi,
Discussions related to Babel are currently distributed across three
distrinct mailing-lists (babel-users@alioth, babel@ietf, bird-users), and
I'm a little concerned that those of you who are subscribed to just one of
them are missing out on the whole picture. Since I'm on strike today, and
> btw, there is one question that i noticed. If an Update is ignored for
> semantic reasons (e.g. update with valid metric, but missing next hop or
> router id), should it update last prefix with P-flag?
Such a packet would be incorrect. What to do in presence of an incorrect
packet is left to
> I just though that the default value for the option is enabled, but
> perhaps it should be enabled only if such routes are supported by
> platform code (i.e. enabled on Linux, but disabled on BSD, as we do
> not support such routes on BSD).
IMHO, it should not be possible to enable v4-via-v6
> 1) Changed the name of the option to 'extended next hop', for consistency
> with BGP (and in the future also with other protocols). As the option is
> enabled by default, the name likely does not matter that much.
I rather like v4-via-v6, which succintly and clearly states what it is
about.
Hi,
Babeld 1.12.2 is available from
https://www.irif.fr/~jch/software/files/babeld-1.12.2.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.12.2.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
This is a pure
>> I took some time to put this to a test. The Go program here
>> https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the
>> lock - but a large % of runtime holding the lock.
> Thanks for the benchmark. You're right: if you have hundreds of
> goroutines doing nothing but acquiring a
> I've just read this draft and I must say that it looks nice, simple and
> clean.
Thanks for the kind words. I've read your comments, and agree on all counts.
-- Juliusz
>> Thanks for the answer! I hope it's not too annoying when I ask, however
>> I can not find any information about this online: Are there also plans
>> to implement the Babel RTT extension?
> The core team doesn't have this in current plans. As there is no RFC for
> this yet, it's under my radar.
>>> We do actually update the garbage collection time regardless of the
>>> route metric in the regular update function (but not when sending an
>>> explicit retraction). I think that's OK, though?
>> Does that mean that a retracted route never expires?
> Hmm, no, this is the garbage collection
> This has been clarified in RFC8966 as: "Note that the feasibility
> distance is not updated and the garbage-collection timer is not reset
> when a retraction (an update with infinite metric) is sent."
>
> The feasibility distance is only updated if the metric is lower, which
> is never true for
> Introduce a strict-inequality version of the modulo-comparison for this
> purpose.
Thanks.
I'm a little worried about the code around line 1017:
struct babel_source *s = babel_get_source(p, e, e->router_id);
s->expires = current_time() + BABEL_GARBAGE_INTERVAL;
if
> The problematic bit is, I think, 's' in babel_handle_update can be NULL
> because nothing ensures the babel_source for a particular neighbour
> actually exists here:
s will be passed to babel_is_feasible, which returns true if s is null.
Later on, s is only used if feasible is false, in which
> The problematic bit is, I think, 's' in babel_handle_update can be NULL
> because nothing ensures the babel_source for a particular neighbour
> actually exists here:
s will be passed to babel_is_feasible, which returns true if s is null.
Later on, s is only used if feasible is false, in which
1 - 100 of 3648 matches
Mail list logo
