UDP instead of TCP?
Joe Hillenbrand
Johannes Schlumberger
> I've been interested in Phantom for a while, and I am hoping to start tinkering
> with it soon.
Thanks for your interest.
> I was talking about Phantom to a bunch of people at DefCon this weekend, and
> somebody mentioned that it is a common mistake among darknet implementations to
> use TCP. He suggested that UDP would be the smarter option�for communication
> between nodes in the routing path, though the end-to-end communication should
> still be TCP.�
I was at defcon, too :-) Did we maybe run into each other at the privacy
presenters party Friday night?
> The rational is that OK for the path to be lossy, since ethernet and wireless
> are also lossy and that using UDP could improve throughput. I imagine that this
> would improve performance among the routing nodes, since they can choose which
> packets they are able to forward, and it might make them more resistant to
> DDoS. I also imagine that this would make a high available routing
> implementation easier.
>
> I was wondering if anyone else has thought about this idea.
I have thought about it and I see the point. However I do not understand the
suggestion for Phantom - user (application) data is never relayed through a
routing path at all - a routing path is only used to construct routing tunnels
as infrastructure - this should not be lossy because then it will fail. The
routing tunnels itself (relaying application data) could be UDP - is that what
you mean? That would be the equivalency of the end to end communication.
Enclosed in this routing tunnel there is the real application connection,
running TCP or UDP - so for routing tunnels we actually end up having the case
of transporting TCP and or UDP over TCP currently which is not very nice.
The reason why the current implementation does it that way is mainly because
libopenssl does not offer UDP support and I used this library for the routing
tunnels. So changing that later on might be a good idea to increase performance.
Johannes
Magnus Bråding
Welcome to the discussion, and thanks for your interest in Phantom!
Now, please don't be insulted in any way by my replies below, their
"edge" is aimed exclusively at the people who carelessly throw around
the opions you mention having heard here below, without any deeper
understanding, reasoning or further explanation (most of the time based
solely on the single fact that "they heard somewhere that UDP is faster
than TCP"). The reason that I'm a little tired of answering them is that
they, just like you say, are quite common.
But you can never be sure, maybe this time I will get some solid
reasoning back, and in that case no one will be happier than me, so here
we go... :-)
> I was talking about Phantom to a bunch of people at DefCon this weekend,
> and somebody mentioned that it is a common mistake among darknet
> implementations to use TCP.
In my experience, it's an even more common mistake to think that you can
design and implement your own flow-control over UDP that will be faster
than TCP for transfers of static data.
> He suggested that UDP would be the smarter
> option for communication between nodes in the routing path, though the
> end-to-end communication should still be TCP.
Could you then please ask him exactly how it would be more efficient to:
A) Implement your own TCP-to-UDP flow control interface
B) Necessitate the resending and requests-for-resending of packets over
an entire routing path (i.e. multiple hops of devices)
C) Drop packets intentionally instead of just dividing the available
bandwidth between currently active tunnels
than to just let TCP do this _locally_ and automatically between each
node? Also, if you've looked into how the encryption and communication
over Phantom routing paths work, you'd see that order verification and
resendings of packets between nodes (especially over multiple hops)
would be a total nightmare on so many levels.
> The rational is that OK for the path to be lossy, since ethernet and
> wireless are also lossy and that using UDP could improve throughput.
First of all I see the following false premise in this reasoning:
The pure act of using UDP will not improve throughput for transfers of
static data sets.
I also see that the following side-effect is seemingly ignored:
Dropped/reordered packets will be _very_ expensive to correct when
performed on an end-to-end basis in a routing path, and that's even
_without_ taking into account any of the side-effects on anonymity and
communication efficiency that would arise due to
Phantom/anonymity-specific reasons.
> I imagine that this would improve performance among the routing nodes,
> since they can choose which packets they are able to forward
More exactly why would it do that, and how would they know which packets
to choose (since they have no idea about what's in them)?
> and it might make them more resistant to DDoS.
More exactly how would that be?
> I also imagine that this would make a high available routing implementation easier.
High-availability routing paths are problematic mostly due to anonymity
and integrity aspects, not network communication aspects. Not much focus
has been put on this specific area in Phantom so far though, so I'll
refrain to saying too much more than that at this point.
> I was wondering if anyone else has thought about this idea.
Many people have had the same idea (or rather "spinal reflex", due to
the false and widespread notion that UDP would be faster that TCP under
all conditions), yes, but extremely few have been able to actually back
it up with some detailed (and foremost valid) reasoning. Hopefully you
will be the first one though, and in that case I'd be nothing but happy. :-)
On a related note, the traffic connected to the network database may in
some ways be beneficial to use UDP for, but in that case it is rather a
fully intentional trade-off for robustness and increased difficulty of
external identification and blocking of the Phantom traffic as a whole.
Regards,
Magnus
Magnus Bråding
> libopenssl does not offer UDP support and I used this library for the routing
> tunnels.
I may very well have completely misunderstood something here, but isn't
that what the DTLS support in OpenSSL is?
Or does libopenssl not support the full contents of OpenSSL? Or did I
misunderstand something else?
Regards,
Magnus
Johannes Schlumberger
My bad. I never stumbled upon this in the whole libssl documentation during my
implementation (which in my defense is not known to be very extensive). Good to
know, thanks.
regards,
Johannes
JoE
I was at defcon, too :-) Did we maybe run into each other at the privacy
presenters party Friday night?
JoE
Now, please don't be insulted in any way by my replies below, their
"edge" is aimed exclusively at the people who carelessly throw around
the opions you mention having heard here below, without any deeper
understanding, reasoning or further explanation (most of the time based
solely on the single fact that "they heard somewhere that UDP is faster
than TCP"). The reason that I'm a little tired of answering them is that
they, just like you say, are quite common.
Could you then please ask him exactly how it would be more efficient to:
A) Implement your own TCP-to-UDP flow control interface
B) Necessitate the resending and requests-for-resending of packets over
an entire routing path (i.e. multiple hops of devices)C) Drop packets intentionally instead of just dividing the available
bandwidth between currently active tunnels
than to just let TCP do this _locally_ and automatically between each
node? Also, if you've looked into how the encryption and communication
over Phantom routing paths work, you'd see that order verification and
resendings of packets between nodes (especially over multiple hops)
would be a total nightmare on so many levels.
> The rational is that OK for the path to be lossy, since ethernet and
> wireless are also lossy and that using UDP could improve throughput.First of all I see the following false premise in this reasoning:
The pure act of using UDP will not improve throughput for transfers of
static data sets.I also see that the following side-effect is seemingly ignored:
Dropped/reordered packets will be _very_ expensive to correct when
performed on an end-to-end basis in a routing path, and that's even
_without_ taking into account any of the side-effects on anonymity and
communication efficiency that would arise due to
Phantom/anonymity-specific reasons.
> I imagine that this would improve performance among the routing nodes,
> since they can choose which packets they are able to forwardMore exactly why would it do that, and how would they know which packets
to choose (since they have no idea about what's in them)?
> and it might make them more resistant to DDoS.
More exactly how would that be?
On a related note, the traffic connected to the network database may in
some ways be beneficial to use UDP for, but in that case it is rather a
fully intentional trade-off for robustness and increased difficulty of
external identification and blocking of the Phantom traffic as a whole.
Magnus Bråding
> On a related note, the traffic connected to the network database may in
> some ways be beneficial to use UDP for, but in that case it is rather a
> fully intentional trade-off for robustness and increased difficulty of
> external identification and blocking of the Phantom traffic as a whole.
>
> I'm not sure what you mean here. Are you suggesting that TCP would be
> harder to implement for the network database? How so?
What I mean is that contrary to the other parts of the Phantom protocol
communication, a typical distributed data structure of redundant nature
(e.g. a typical DHT), which is most likely what the final network
database implementation will be based on to some degree, can be quite
optimal for UDP traffic use, since the typical conditions in such a case
would be:
1) Continuous communication with many different "random" peers.
2) Only small amounts of data communicated each time
3) No problems if data would sometimes be dropped, in the typical case
4) No anonymization of generic data transmissions involved
Such a situation may result in an unnecessary overhead for connection
establishment when using TCP/SSL. Probably not enough to be a practical
problem there either though, but theoretically anyway, and that's why I
want to emphasize that in this particular case the use of TCP/SSL is an
intentional trade-off for robustness and increased difficulty of
external protocol identification and blocking, contrary to the rest of
the Phantom protocol communication, where UDP does not make much sense
at all as far as I can tell, neither theoretically nor practically.
Thanks for your interest again anyway, and please keep the questions and
suggestions coming!
Regards,
Magnus
Joe Hillenbrand
--
You received this message because you are subscribed to the Google Groups "Phantom Protocol" group.
To post to this group, send email to phantom-...@googlegroups.com.
To unsubscribe from this group, send email to phantom-protoc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/phantom-protocol?hl=en.
JoE
I only roughly understood the nature of the actual wire protocol. It looks
like SSL node-to-node, with a second SSL stream going on inside for the
end-to-end encryption? If that's the case, then there's only one
communication channel and only one flow of traffic, then having only one tcp
stack is fine. It's when you have TCP running over TCP, or even just
multiple TCP/UDP connections all running over a single TCP connection that
you start having problems.
I'm not sure if that is true, or not. If it is - one 'tunneled' connection
to one 'phantom' connection - then please reply back to Magnus stating that
I thought it was more like IPSEC rather than sequential TCP proxies.
If, however, there's multiple connections all over a single TCP connection,
than I'd quite happily expand on the perils of that approach. I'd want to
be sure that's actually the case before putting pen to paper, though.
Magnus Bråding
yes, that's correct. I.e. you need not worry about multiple connections
being handled over single TCP connections, so this should calm you down.
Regards,
Magnus
> --
> You received this message because you are subscribed to the Google
> Groups "Phantom Protocol" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/phantom-protocol/-/LyCxwzkWNLQJ.