2 ms·

Sadly the proliferation of middleboxes means that deploying a new Layer 4 is all but impossible: * https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pr

Sadly the proliferation of middleboxes means that deploying a new Layer 4 is all but impossible: * https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pr... * https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... Curious to know if things can every move towards a point of allowing things. I know in many firewall 'languages' do have something like "allow tcp/443" or "allow udp/53" for nomenclature: perhaps something like "allow stream/443" and "allow dgram/53" to include (e.g.) TCP/SCTP and UDP/DCCP would allow more flexibility.

tsimionescu 1y ago
I never really understood this complaint. UDP adds such a tiny and useful header on top of IP that it hardly seems meaningful to reinvent the wheel instead of just using it.
- throw0101c 1y ago
  See §Problem Space on what it was thought that UDP lacked that caused the creation of DCCP: * https://datatracker.ietf.org/doc/html/rfc4336#section-2 https://datatracker.ietf.org/doc/html/rfc4336#section-2
  - tsimionescu 1y ago
    I'm not asking why you'd need a new transport protocol, that much is clear. The question is what is the disadvantage of building this new protocol on top of UDP, especially if you don't expect to work with middlebox developers to add special features for your new protocol. The only thing I get from that document that answers this question to some extent is the extra overhead of the checksum field in UDP headers. In other places, they generally don't seem to actually discuss the option of building a QUIC-like transport, that is a transport-layer protocol that still exists on top of the UDP skeleton.
    - anticensor 1y ago
      Your box should just treat that unknown protocol as a raw IP traffic, instead of dropping it.
      - tsimionescu 1y ago
        Probably, but again: why would you want to send raw IP traffic rather than UDP? What are the disadvantages of building your protocol on top of UDP instead of building it on top of raw IP, for an Internet protocol?

tsimionescu 1y ago

I never really understood this complaint. UDP adds such a tiny and useful header on top of IP that it hardly seems meaningful to reinvent the wheel instead of just using it.

throw0101c 1y ago
See §Problem Space on what it was thought that UDP lacked that caused the creation of DCCP: * https://datatracker.ietf.org/doc/html/rfc4336#section-2 https://datatracker.ietf.org/doc/html/rfc4336#section-2
- tsimionescu 1y ago
  I'm not asking why you'd need a new transport protocol, that much is clear. The question is what is the disadvantage of building this new protocol on top of UDP, especially if you don't expect to work with middlebox developers to add special features for your new protocol. The only thing I get from that document that answers this question to some extent is the extra overhead of the checksum field in UDP headers. In other places, they generally don't seem to actually discuss the option of building a QUIC-like transport, that is a transport-layer protocol that still exists on top of the UDP skeleton.
  - anticensor 1y ago
    Your box should just treat that unknown protocol as a raw IP traffic, instead of dropping it.
    - tsimionescu 1y ago
      Probably, but again: why would you want to send raw IP traffic rather than UDP? What are the disadvantages of building your protocol on top of UDP instead of building it on top of raw IP, for an Internet protocol?