4 ms·

> don't agree with the view that NAT is evil NAT is a nightmare for p2p applications. For algorithms that send short messages to many different peers the overh

by jamii 16y ago

> don't agree with the view that NAT is evil NAT is a nightmare for p2p applications. For algorithms that send short messages to many different peers the overhead of using STUN for every connection is enormous. See eg http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81.2014&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81....

tptacek 16y ago
P2P is a nightmare because every application is expected to provide its own connection fabric. In a content-addressed overlay network --- and there are many huge deployed examples of these deployed --- you wouldn't need to do the STUN chicken dance every time you wanted to add a peer. If this all sounds hand-wavy, well, it's already the mechanism used by the exchanges and ECNs to route stock information, and it's already a mechanism used to build CDNs. It's a considerably more straightforward evolutionary path for the Internet than forklifting out every IPv4-aware device or software package.
- drdaeman 16y ago
  Not every P2P revolves around "content". The most well-known example would be Skype and SIP.
  - tptacek 16y ago
    Content-addressed networking doesn't imply that content is being transmitted in discrete units; it implies (what Tibco would call) subject-based addressing, and the notion of publish/subscribe. It works just fine for unicast, and even in strictly unicast situations, there are plenty of cases (conference calls, for instance) where "subscribe" turns out to be useful.
- jamii 16y ago
  > P2P is a nightmare because every application is expected to provide its own connection fabric Well someone has to write the connection fabric, even in a content-addressed overlay. Writing a DHT that performs NAT traversal is just as difficult as for any other P2P application. See http://www.slideshare.net/vschiavoni/dht-and-nat http://www.slideshare.net/vschiavoni/dht-and-nat for some examples. CDNs have it easy because they control the network the servers are on. Writing p2p applications for the internet at large is much harder than it should be because of NAT.
  - tptacek 16y ago
    I think you're missing my point. It's hard to write P2P applications for "the Internet at large" for the same reason that it's hard to write a web browser in assembly language: you're targeting the wrong layer of abstraction. What I'm suggesting is that if instead of a futile effort to convert the Internet to a new, Cisco-sponsored network protocol we invested in adoption of a few standard overlay networks, people could write P2P applications that targeted overlays instead of the Internet, and IP addresses would matter only as much as Ethernet addresses matter today.
    - jamii 16y ago
      You mean something like this http://libswift.org/ http://libswift.org/ ? I think I understand your point now. What we need is a standard mechanism for addressing devices. I'm not sure that building another layer on top of IPv4 would be any cheaper in the long run than converting to IPv6, given the amount of overhead caused by NAT traversal. This overhead also constrains the design of the overlay - you end up having static connections which are kept open as long as possible to avoid the connection overhead. If we could send UDP packets directly between every pair of peers without paying for the overhead of NAT traversal it would open up a lot of possibilities.
      - tptacek 16y ago
        I think anything built on top of IPv4 must be less expensive than IPv6, simply because the cost of converting to IPv6 is deceptively high and because we'll inevitably need to build an overlay layer anyhow. The overhead of NAT is irrelevant on overlay networks; it scales linearly with the number of direct connections established (OSPF would call them "adjacencies"), but probably scales logarithmically with the number of relationships on the network.
        jamii 16y ago
        > it scales linearly with the number of direct connections established Yes, assuming that the overlay algorithm actually establishes direct connections with a small number of peers. That's the way most overlays are designed because they need to reduce the cost of establishing a connection. By way of contrast, I recently worked on a gossip algorithm for producing uniformly distributed peer samples with no warmup time. This algorithm doesnt maintain an adjacency graph at all. Instead it sends a single udp datagram to a different peer at every tick (100 ms for the test system). Its a really simple algorithm that provides stronger guarantees than any existing peer sampling service but replace each datagram with a NAT traversal and the overhead kills it.

by jamii 16y ago

tptacek 16y ago

P2P is a nightmare because every application is expected to provide its own connection fabric. In a content-addressed overlay network --- and there are many huge deployed examples of these deployed --- you wouldn't need to do the STUN chicken dance every time you wanted to add a peer. If this all sounds hand-wavy, well, it's already the mechanism used by the exchanges and ECNs to route stock information, and it's already a mechanism used to build CDNs. It's a considerably more straightforward evolutionary path for the Internet than forklifting out every IPv4-aware device or software package.

drdaeman 16y ago
Not every P2P revolves around "content". The most well-known example would be Skype and SIP.
- tptacek 16y ago
  Content-addressed networking doesn't imply that content is being transmitted in discrete units; it implies (what Tibco would call) subject-based addressing, and the notion of publish/subscribe. It works just fine for unicast, and even in strictly unicast situations, there are plenty of cases (conference calls, for instance) where "subscribe" turns out to be useful.
jamii 16y ago
> P2P is a nightmare because every application is expected to provide its own connection fabric Well someone has to write the connection fabric, even in a content-addressed overlay. Writing a DHT that performs NAT traversal is just as difficult as for any other P2P application. See http://www.slideshare.net/vschiavoni/dht-and-nat http://www.slideshare.net/vschiavoni/dht-and-nat for some examples. CDNs have it easy because they control the network the servers are on. Writing p2p applications for the internet at large is much harder than it should be because of NAT.
- tptacek 16y ago
  I think you're missing my point. It's hard to write P2P applications for "the Internet at large" for the same reason that it's hard to write a web browser in assembly language: you're targeting the wrong layer of abstraction. What I'm suggesting is that if instead of a futile effort to convert the Internet to a new, Cisco-sponsored network protocol we invested in adoption of a few standard overlay networks, people could write P2P applications that targeted overlays instead of the Internet, and IP addresses would matter only as much as Ethernet addresses matter today.
  - jamii 16y ago
    You mean something like this http://libswift.org/ http://libswift.org/ ? I think I understand your point now. What we need is a standard mechanism for addressing devices. I'm not sure that building another layer on top of IPv4 would be any cheaper in the long run than converting to IPv6, given the amount of overhead caused by NAT traversal. This overhead also constrains the design of the overlay - you end up having static connections which are kept open as long as possible to avoid the connection overhead. If we could send UDP packets directly between every pair of peers without paying for the overhead of NAT traversal it would open up a lot of possibilities.
    - tptacek 16y ago
      I think anything built on top of IPv4 must be less expensive than IPv6, simply because the cost of converting to IPv6 is deceptively high and because we'll inevitably need to build an overlay layer anyhow. The overhead of NAT is irrelevant on overlay networks; it scales linearly with the number of direct connections established (OSPF would call them "adjacencies"), but probably scales logarithmically with the number of relationships on the network.
      - jamii 16y ago
        > it scales linearly with the number of direct connections established Yes, assuming that the overlay algorithm actually establishes direct connections with a small number of peers. That's the way most overlays are designed because they need to reduce the cost of establishing a connection. By way of contrast, I recently worked on a gossip algorithm for producing uniformly distributed peer samples with no warmup time. This algorithm doesnt maintain an adjacency graph at all. Instead it sends a single udp datagram to a different peer at every tick (100 ms for the test system). Its a really simple algorithm that provides stronger guarantees than any existing peer sampling service but replace each datagram with a NAT traversal and the overhead kills it.