3 ms·

> HTTP/3 runs over QUIC – an encrypted general-purpose transport protocol that multiplexes multiple streams of data on a single connection. Kind of sucks that

> HTTP/3 runs over QUIC – an encrypted general-purpose transport protocol that multiplexes multiple streams of data on a single connection. Kind of sucks that SCTP, which also allows for multiplexing, never caught on for general use—probably because lack of support in various mid-network network boxen. I guess we're generally stuck with tunnelling everything over HTTP (TCP and UDP) going forward. Every other kind of protocol implementation is out of the question because of NAT and various proxies.

Orphis 5y ago
It would help to have quality implementations of the full SCTP specs first.
EvanAnderson 5y ago
Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses, SCTP was used for everything we use TCP for, and "well-known ports" were eschewed in favor of DNS SRV records for service location (and all the goodness they bring).
- p_l 5y ago
  Sounds a bit like half way to OSI network style
  - EvanAnderson 5y ago
    Perhaps. When OSI was still a going concern I was far too young to have paid attention. Glancing at the PDF for the X.224 spec[0] I see things like "The initiator may assign the transport connection to an existing network connection of which it is the owner or to a new network connection (see Note 1) which it creates for this purpose." In X.225[1] I see some references to re-using transport connections. (Egad, the ITU documentation is much less fun to read than RFCs.) It certainly looks like the layering in the OSI protocols is taken nearly to the absurd. I do know Vint Cerf has stated using the IP address as the connection endpoint identifier in TCP and UDP was a mistake.[2] [0] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.224-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [1] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.225-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [2] https://youtu.be/t9M0RPNr9qg?t=2229 https://youtu.be/t9M0RPNr9qg?t=2229
- throw0101a 5y ago
  Given that we haven't run out of (Ethernet) MAC addresses yet, even 48 bits may have been enough (until this point).
  - BenjiWiebe 5y ago
    MAC addresses are link-local, not global. Your device and my device could have the same MAC address and everything works fine until we find ourselves on the same L2 network. And there's practical limits to how large a single L2 network can be, and it's way smaller than 48 bits of space.
    - throw0101a 5y ago
      Yes, I know. But I think you misunderstood this sub-thread. IPv4 has 32-bit addresses, and we've run out of those, which necessitated a new protocol (IPv6) with a larger addresses space (and the use of NAT until it's rolled out everywhere). However, the GP said: > Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses […] Which would have allowed for continued use of this alternate-history-IPv4 without having to NAT and without all the work to enable IPv6. My observation was that 64b addresses would probably not not even been needed, as we're using "only" 48b for Ethernet MAC addresses and we haven't run out of those yet, so an alternative-history-IPv4 with "only" 48b addresses (instead of 64b or IPv6's 128b) would probably also been enough. At least until now, early 2022. I'm sure at some point the alternate-history-IPv4 addresses would have run out, and an alternate-history-IPv5/6 would have had to have been developed eventually too. > And there's practical limits to how large a single L2 network can be, and it's way smaller than 48 bits of space. Well IPv6 subnets are /64, so ¯\_(ツ)_/¯. (Though 2^64 hosts are not actually expected to live in a single subnet: that's the equivalent of four billion Internets.)
      - NavinF 5y ago
        > an alternative-history-IPv4 with "only" 48b addresses (instead of 64b or IPv6's 128b) would probably also been enough MAC address can be assigned in arbitrarily small blocks whereas IP addresses must be assigned as large prefixes, ideally one prefix per org. Otherwise the internet routing table would be too large. I don’t think 2^48 is reasonable right now without NAT and it certainly won’t be enough in the near future. Also 48b MAC addresses are kinda small. InfiniBand uses 64b and newer protocols should do the same.

Orphis 5y ago

It would help to have quality implementations of the full SCTP specs first.

EvanAnderson 5y ago

Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses, SCTP was used for everything we use TCP for, and "well-known ports" were eschewed in favor of DNS SRV records for service location (and all the goodness they bring).

p_l 5y ago
Sounds a bit like half way to OSI network style
- EvanAnderson 5y ago
  Perhaps. When OSI was still a going concern I was far too young to have paid attention. Glancing at the PDF for the X.224 spec[0] I see things like "The initiator may assign the transport connection to an existing network connection of which it is the owner or to a new network connection (see Note 1) which it creates for this purpose." In X.225[1] I see some references to re-using transport connections. (Egad, the ITU documentation is much less fun to read than RFCs.) It certainly looks like the layering in the OSI protocols is taken nearly to the absurd. I do know Vint Cerf has stated using the IP address as the connection endpoint identifier in TCP and UDP was a mistake.[2] [0] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.224-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [1] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.225-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [2] https://youtu.be/t9M0RPNr9qg?t=2229 https://youtu.be/t9M0RPNr9qg?t=2229
throw0101a 5y ago
Given that we haven't run out of (Ethernet) MAC addresses yet, even 48 bits may have been enough (until this point).
- BenjiWiebe 5y ago
  MAC addresses are link-local, not global. Your device and my device could have the same MAC address and everything works fine until we find ourselves on the same L2 network. And there's practical limits to how large a single L2 network can be, and it's way smaller than 48 bits of space.
  - throw0101a 5y ago
    Yes, I know. But I think you misunderstood this sub-thread. IPv4 has 32-bit addresses, and we've run out of those, which necessitated a new protocol (IPv6) with a larger addresses space (and the use of NAT until it's rolled out everywhere). However, the GP said: > Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses […] Which would have allowed for continued use of this alternate-history-IPv4 without having to NAT and without all the work to enable IPv6. My observation was that 64b addresses would probably not not even been needed, as we're using "only" 48b for Ethernet MAC addresses and we haven't run out of those yet, so an alternative-history-IPv4 with "only" 48b addresses (instead of 64b or IPv6's 128b) would probably also been enough. At least until now, early 2022. I'm sure at some point the alternate-history-IPv4 addresses would have run out, and an alternate-history-IPv5/6 would have had to have been developed eventually too. > And there's practical limits to how large a single L2 network can be, and it's way smaller than 48 bits of space. Well IPv6 subnets are /64, so ¯\_(ツ)_/¯. (Though 2^64 hosts are not actually expected to live in a single subnet: that's the equivalent of four billion Internets.)
    - NavinF 5y ago
      > an alternative-history-IPv4 with "only" 48b addresses (instead of 64b or IPv6's 128b) would probably also been enough MAC address can be assigned in arbitrarily small blocks whereas IP addresses must be assigned as large prefixes, ideally one prefix per org. Otherwise the internet routing table would be too large. I don’t think 2^48 is reasonable right now without NAT and it certainly won’t be enough in the near future. Also 48b MAC addresses are kinda small. InfiniBand uses 64b and newer protocols should do the same.