[tahoe-lafs-trac-stream] [Tahoe-LAFS] #169: tcp hole-punching!

[Tahoe-LAFS]

#169: tcp hole-punching!
------------------------------+----------------------------------------
     Reporter:  zooko         |      Owner:  ghazel
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  undecided
    Component:  code-network  |    Version:  0.6.0
   Resolution:                |   Keywords:  firewall availability gsoc
Launchpad Bug:                |
------------------------------+----------------------------------------

Comment (by exarkun):

 To choose a milestone, let's work backwards from an end-user-facing goal.
 What is that in this case?  Real servers rarely have to deal with NAT.
 They just get public IP addresses.  Perhaps the goal is related to
 operation by "home" users?  That is, to allow me to run a listening Tahoe
 node (so, not just a storage client - a storage server and/or an
 introducer) on my consumer-grade network connection where I have no
 publicly routeable address to make my servers listen on.

 Oops, wait.  Is that really relevant?  Can I TCP hole-punch through
 carrier-grade NAT (CGN)?  Wikipedia vaguely nods towards "yes" (no
 citations).  All of my hole-punching experience is with consumer-grade
 routers so I can't say first-hand.  You have to be able to hole-punch
 through CGN to meaningfully improve the home user experience now, I think.

 Well ... maybe there are mild ease-of-use improvements from just defeating
 consumer-grade router NAT.  Tahoe could deal with UPnP instead of making
 me click buttons on my router.

 Suppose we can do some or all of those things.  The end result is that
 Tahoe storage nodes and introducers can run on my low-end network
 connection.  This helps out ... friendnet operation, perhaps?  A group of
 "friends" are more likely to have a NAT'd server among them (it's not
 until you have two that you actually need help here.  still.).

 If you wanted a remote control for your client node then the same
 requirement would apply, I suppose.  You want the remote control to be
 able to connect back to your client node regardless of intervening network
 topology.  There's a lot of other work required before we know if/how we
 can have such remote controls though.

 I think "Grid Management" is essentially orthogonal.  It's actually about
 efforts related to ticket:2916 which is a very specific kind of grid
 management.

 If we had some kind of "friendnet" milestone it might make sense there.
 If we had some kind of "remote control" milestone it might make sense
 there.
 It might even make sense if we sliced the problem differently and had a
 "maximum network compatibility" milestone that included all of the hole
 punching, UPnP, STUN, etc tickets.

 None of those milestones exist yet, though, and I wouldn't suggest
 creating them just to have a place to put this ticket.  I think we need to
 plan a roadmap first and then we'll see what milestones are on it and we
 can sort tickets into them.  There will be *lots* of tickets that don't
 fall into a milestone in the near-term future based on such a roadmap and
 that's fine (or at least, that's life).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/169#comment:18>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage