4 ms·

UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. In that spirit

by tbocek 11mo ago

UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. In that spirit, we are currently exploring this with: https://github.com/tbocek/qotp https://github.com/tbocek/qotp and https://github.com/qh-project/qh https://github.com/qh-project/qh The main idea is to have a simple encryption (ed25519/chacha20+poly1305) for encryption in the transport layer, on top of that then qh, where certs are use for signing content. With out of band key exchange, you can establish a connection after you successfully punched a hole. However, its not QUIC compatible in any way (https://xkcd.com/927 https://xkcd.com/927)

Imustaskforhelp 11mo ago
the https://github.com/qh-project/qh https://github.com/qh-project/qh link doesn't work for what its worth.
jcelerier 11mo ago
> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. ... how does that work when the network disallows UDP altogether?
- octoberfranklin 11mo ago
  That is not as common as you think, and will get less common as QUIC grows in popularity. If you're really really desperate you can send UDP packets with fake TCP headers (i.e. you aren't actually doing any congestion control or retransmission) but you have to control both ends of the connection for that. And there's ICMP.
  - bnjms 11mo ago
    Blocking UDP to Outside and non-ping udp to Outside is common. It will remain common as long as servers fall back. And exceptions will be made for problem domains.
throw0101d 11mo ago
> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. "Cannot" is a strong word: > UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint. * https://en.wikipedia.org/wiki/UDP_hole_punching#Overview https://en.wikipedia.org/wiki/UDP_hole_punching#Overview I've also heard lots of people complain about how they're stuck behind CG-NAT and various P2P things do not work.
octoberfranklin 11mo ago
> and https://github.com/qh-project/qh https://github.com/qh-project/qh This link is 404. QOTP looks really cool. Like what QUIC would be if DJB were in charge of it.
- tbocek 11mo ago
  Thx, I cannot change my previous message, the QH is set to private, as me and my students are working on it. It will be made public next month. The qh:// protocol, we have just started, and we only focused on simplifying the header as an alternative to HPACK / QPACK. Currently we are collecting headers for identifying what should go into our static table for lookup, and for benchmarking. For simplicity, we decided against dynamic tables or huffman-style encoding/decoding. Just a table with often used header/values, the rest is binary encoded with no further compression.

by tbocek 11mo ago

Imustaskforhelp 11mo ago

the https://github.com/qh-project/qh https://github.com/qh-project/qh link doesn't work for what its worth.

jcelerier 11mo ago

> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. ... how does that work when the network disallows UDP altogether?

octoberfranklin 11mo ago
That is not as common as you think, and will get less common as QUIC grows in popularity. If you're really really desperate you can send UDP packets with fake TCP headers (i.e. you aren't actually doing any congestion control or retransmission) but you have to control both ends of the connection for that. And there's ICMP.
- bnjms 11mo ago
  Blocking UDP to Outside and non-ping udp to Outside is common. It will remain common as long as servers fall back. And exceptions will be made for problem domains.

throw0101d 11mo ago

> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. "Cannot" is a strong word: > UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint. * https://en.wikipedia.org/wiki/UDP_hole_punching#Overview https://en.wikipedia.org/wiki/UDP_hole_punching#Overview I've also heard lots of people complain about how they're stuck behind CG-NAT and various P2P things do not work.

octoberfranklin 11mo ago

> and https://github.com/qh-project/qh https://github.com/qh-project/qh This link is 404. QOTP looks really cool. Like what QUIC would be if DJB were in charge of it.

tbocek 11mo ago
Thx, I cannot change my previous message, the QH is set to private, as me and my students are working on it. It will be made public next month. The qh:// protocol, we have just started, and we only focused on simplifying the header as an alternative to HPACK / QPACK. Currently we are collecting headers for identifying what should go into our static table for lookup, and for benchmarking. For simplicity, we decided against dynamic tables or huffman-style encoding/decoding. Just a table with often used header/values, the rest is binary encoded with no further compression.