<div dir="ltr">Allow me to second that - for some applications (Internet of Things being the one I'm working on), the volume of data exchanged is very small, so there isn't much chance for packets to be lost or retransmitted. OnionCat + Tor simplify development immensely by giving each node a fixed IPv6 address, even behind NAT. You no longer have to _design_ the service for IoT, you just run it on the node and it's immediately accessible over IPv6. It's not perfect in terms of network protocol encapsulation but it's "good enough". <a href="https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good">https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good</a> :)<div><br></div><div>Razvan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 29, 2016 at 2:23 AM, grarpamp <span dir="ltr"><<a href="mailto:grarpamp@gmail.com" target="_blank">grarpamp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 28, 2016 at 11:30 AM, dawuud <<a href="mailto:dawuud@riseup.net">dawuud@riseup.net</a>> wrote:<br>
> Are you aware of Tahoe-LAFS?<br>
<br>
</span>Don't know if they are, or if they are here, all we have is their short post.<br>
<br>
If they just need an insert and retrieve filestore for small user<br>
bases, there are lots of choices. If they need the more global<br>
and random on demand distribution properties, and even mutually<br>
co-interested long term storage nature of bittorrent, that's harder.<br>
<br>
Today people can use onioncat to escape IPv4 address space limitations,<br>
provide UDP transport, provide configuration free on demand any node to<br>
any node IP network semantics for use by existing applications.<br>
Mass bittorrent / bitcoin / p2p apps over a private network such as<br>
HS / eep happen to typically need and match that.<br>
<span class=""><br>
> Yes but then you are suggesting TCP on top of TCP via TCP/IPv6/onion/TCP.<br>
<br>
</span>Onioncat is only one extra encapsulation layer. Of course if you run tcp<br>
app over onioncat instead of udp app, you have to think about that too.<br>
But being the top layer, onioncat itself does not have losses, ie any losses<br>
come up from below.... clearnet --> tor --> ocat --> user.<br>
<span class=""><br>
> Do you know what happens when you get packet loss with that protocol layer cake?<br>
> Cascading retransmissions. Non-optimal, meaning shitty.<br>
<br>
</span>For certain applications, expecially bulk background transport, it's actually<br>
quite useable in practice. And people do use voice / video / irc / ssh over<br>
hidden / eep services... of course there are non-optimal systemic issues<br>
there. People will use what they can [tolerate].<br>
<span class=""><br>
> You might be able to<br>
> partially solve this by using a lossy queueing Tun device/application but that<br>
> just makes me cringe.<br>
<br>
</span>That's pretty far beyond anywhere tor network design is<br>
going anytime soon.<br>
<br>
Buffering for reordering datagrams into a queue, maybe partially if the<br>
user doesn't mind possible additional latency. Lossy... not in tcp layers.<br>
<br>
Maybe in ideal world user would supply requirements as ifconfig<br>
request to network, each interface providing different set, user<br>
binds apps to interfaces as needed.<br>
Sliders latency / bandwidth / loss - maybe represented as single<br>
app type config param: voice, irc, bulk, torrent, network tolerant - or<br>
by list of app names.<br>
Or network would monitor and adapt to users traffic.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/<wbr>cgi-bin/mailman/listinfo/tor-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>