Live data from Hacker News

Weave is kinda slow

generictestdomain.net

71–80 of 164 posts

Re: Weave is kinda slow

#71
post #8

flannel appears to be what kubernetes is using as well and I know it is what RedHat is using for their OpenShift platform ontop of k8. It seems like the obvious path forward.

Hi Jeff - if there was a single solution that fit all requirements, then that would be obvious :) However, experience has pointed out that there are differing sets of requirements. Some folks may need the flexibility (say disjunct fabrics) that encap provides, while others need the scale (say 1000's or 10K's of servers) or simplicity (those sort-of go hand-in-hand) that a non-encap data-path provides.

The big question that a system architect needs to ask, if they are designing a system at scale is not "should I use this technique" but "do I NEED to use this technique." We can always add more complexity and technology/layers than we need because we "may need it" in the future, and we almost always end up with a jinga tower when we are done.

So, when laying out your infrastructure, be sure to know what your actual requirements are, and don't add a lot of extraneous capabilities that you have to maintain and trouble-shoot later.

Re: Weave is kinda slow

#72
post #39

Weave has other issues... like they homebrewed their own ECDHE-PSK-based transport encryption protocol on top of NaCl. Homebrewing your own crypto, especially transport encryption which has to solve problems like key exchange, replay attacks, etc is generally the wrong answer. Also, even if they were using a standard transport encryption like SSL/TLS or IPSEC, PSKs are generally frowned upon for anything other than p…

You speak as if SSL/TLS hasn't been a rat's nest of problems.

If they did it competently, there is no reason they couldn't implement their own crypto encapsulation.

As far as why they rolled their own... have you ever actually tried to use IPSec? It's a usability nightmare. It's also problematic in containers due to container permission issues. I suppose they could have used DSSL (datagram SSL) but that'd probably add more overhead than what they did.

I see little real world evidence that this "let the pros handle it" attitude toward crypto is helping.

Re: Weave is kinda slow

#73
post #8

flannel appears to be what kubernetes is using as well and I know it is what RedHat is using for their OpenShift platform ontop of k8. It seems like the obvious path forward.

Hi Jeff - if there was a single solution that fit all requirements, then that would be obvious :) However, experience has pointed out that there are differing sets of requirements. Some folks may need the flexibility (say disjunct fabrics) that encap provides, while others need the scale (say 1000's or 10K's of servers) or simplicity (those sort-of go hand-in-hand) that a non-encap data-path provides. The big questio…

I want to make one edit, I should have said "need the flexibility" instead of "may need the flexibility". Both the scale and the flexibility can be hard requirements. I don't want folks to think that I am saying that scale trumps flexibility/disjunct fabrics. They both are equal, if that is the environment that you operate in. Again, full disclosure, I'm with the project calico team.

Re: Weave is kinda slow

#74
post #39

Weave has other issues... like they homebrewed their own ECDHE-PSK-based transport encryption protocol on top of NaCl. Homebrewing your own crypto, especially transport encryption which has to solve problems like key exchange, replay attacks, etc is generally the wrong answer. Also, even if they were using a standard transport encryption like SSL/TLS or IPSEC, PSKs are generally frowned upon for anything other than p…

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption https://twitter.com/lclarkmichalek/status/544882194456776705

[deleted]

Re: Weave is kinda slow

#75

Earlier quoted context omitted.

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing? Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.

To put it simply, if @monadic were receptive to @lclarkmichalek's ideas, why did he end the conversation?

But let's look at the Tweet in question:

"@lclarkmichalek @weavenetwork please, if it is so simple and robust you are very welcome to contribute a patch."

1. He says "please", which in this case is sarcastic.

2. Then he says "if it is so simple," which is a dismissive way of saying "you think that it's simple, but you're wrong – it's actually very complicated."

3. And also "if it so so ... robust," which is a dismissive way of saying "you think that it's (more) robust, but you're wrong – it isn't."

4. And finally "you are very welcome to contribute a patch," which, first, does not need to be said as presumably anybody knows that they are welcome to submit a patch to an open source project, and second, basically amounts to "so, I'm going to make my problem your problem."

This case is different from a feature request from a user, where "feel free to do it yourself" is slightly less inappropriate. There, what is meant is "this feature is not important enough to warrant our endorsement or any allocation of resources, but if you were to take on the burden entirely yourself, we would consider it."

In this case, what is meant is something more like "we believe that your charge that there is a fundamental issue with our software is false and we are not interested in discussing until you have actually done the work for us," or in other words "fuck you."

I admit, "fuck you" is quite strong for the general case, but the tone of the Tweet warrants that translation.

Re: Weave is kinda slow

#76

Earlier quoted context omitted.

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption https://twitter.com/lclarkmichalek/status/544882194456776705

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

"Fuck you" would have indeed been a more appropriate response to "how dare you try to implement crypto" FUD.

Crypto is hard, but it's no harder than a lot of other hard things. If you think someone's crypto is broken, you could point out why you think it's broken. I see no evidence that consigning crypto to a forbidden zone is going to improve real world security, and the old "mature" cruftpiles seem to manifest problems at least as often as newer systems designed with the benefit of hindsight. For example, any competent designer of a newer system would always authenticate before decrypting-- something that was not clearly understood when SSL was developed.

Re: Weave is kinda slow

#77

Earlier quoted context omitted.

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing? Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.

Also, agree with above post that you should use your own name as here I am awkwardly talking to you in the 3rd person.

Re: Weave is kinda slow

#78
post #9

Networking is a disaster. Kernel level networking is nice, but that requires access to the kernel which you can't provide in a container. Doing so means containers no longer contain. IPV6 was supposed to solve a lot of this by having an address space so huge you could easily give every vm host a few billion IPs. But nobody uses it.

How the heck are you running containers without kernel access? Does your software not malloc or read files or you know... execute?

Containers implement something not unlike SELinux policies. Networking stuff requires the NET_ADMIN permission, which is not set by default.

Re: Weave is kinda slow

#79

Earlier quoted context omitted.

The problem with DPDK is (as I understand it) that it doesn't handle multiplexing the connection between multiple cores/processes/containers (i.e. lack of polling makes scheduling hard/impossible). The nice thing about using the Linux kernel as your data plane is that you can still have all your bog standard routing, in addition to this fun VXLAN/GRE/etc stuff. That said, I haven't ever implemented anything using DPD…

It depends on how you use DPDK. If I use it from the container directly to the NIC, you certainly do loose all of the kernel capabilities. However, we believe (but have not tested) that you can use a DPDK virtual interface in the container/vm (memnic or virtio) that connects to the DPDK driver in the kernel, so the path from the container/VM is 0 copy. The kernel then does it's processing, and then, another DPDK path…

Now that sounds interesting. I'd love to read about that if you ever do move the idea from paper to production :)

Re: Weave is kinda slow

#80

Earlier quoted context omitted.

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption https://twitter.com/lclarkmichalek/status/544882194456776705

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

I find your attitude the ruder. Users of paid products have the right to complain about stuff like that; it's literally what they paid for. Users of open source projects have no such right: if you know what to do, why not make yourself useful instead of bitching out someone who's volunteered their free time to make your life easier? I have very little patience with armchair pundits myself, if you submit a pull request we can happily have a conversation, but everybody's a critic and some of us are trying to get things done.
Post reply on HN