3 ms·

> QUIC is ... the first ... protocol to ... prevent ossification I'd never heard of the term 'ossification' regarding a protocol before. But "QUIC as a soluti

> QUIC is ... the first ... protocol to ... prevent ossification I'd never heard of the term 'ossification' regarding a protocol before. But "QUIC as a solution to protocol ossification" from LWN [1] clears it up: > TCP suffers other problems as well. ... Middleboxes (routers between the endpoints of a connection) interfere with traffic and make it difficult to improve the protocol. They aren't supposed to be looking at TCP headers, but they do so anyway and make decisions based on what they see, often blocking traffic that looks in any way out of the norm. This "ossification" of the protocol makes it nearly impossible to make changes to TCP itself. [1] https://lwn.net/Articles/745590/ https://lwn.net/Articles/745590/

signa11 8y ago
one of the primary reasons for openflow was to work around ‘ossification’ of core internet protocols. almost all seminal sdn/openflow papers (notably those from mckeon) do bring it up...
solotronics 8y ago
This brings up some interesting considerations I personally believe in absolute freedom of speech so from a network engineering perspective this manifests as a personal responsibility to make the networks I control pass packets without discrimination. The public internet is just a conglomeration of seperate private networks that operate under their own sets of rules. To have absolute freedom when passing traffic the underlying protocol should be fully encrypted and probably even hide the source and destination IP address and port. This is a very tough problem to solve technically because you have to know the destination IP to efficiently route a packet.
- keepmesmall 8y ago
  The destination IP could be hidden opportunistically? Send the destination IP for high-priority requests and retry without the destination. Low-priority/long-latency requests would always hide the destination. ... I can't articulate why, but I feel even this introduces a very large amount of hidden complexity. It solves efficient routing and freedom in part, but does not consider privacy.
  - solotronics 8y ago
    I don't see how you can hide destination IP. Each router has to know the destination IP to determine where to send the packet, yes there are some cases such as MPLS/VXLAN/v4VPN where the packet is encapsulated inside more routing info but for it to get to its destination the routers have to have an IP.
    - keepmesmall 8y ago
      If the routers have public keys it's possible, then the client has to determine (some or all points on) the route. I think future protocols will track use and payment via client-provided keys which are somehow linked to their ISP.
jandrese 8y ago
Of course for this reason QUIC is sometimes blocked outright in organizations that deploy those TCP middleboxes.

signa11 8y ago

one of the primary reasons for openflow was to work around ‘ossification’ of core internet protocols. almost all seminal sdn/openflow papers (notably those from mckeon) do bring it up...

solotronics 8y ago

This brings up some interesting considerations I personally believe in absolute freedom of speech so from a network engineering perspective this manifests as a personal responsibility to make the networks I control pass packets without discrimination. The public internet is just a conglomeration of seperate private networks that operate under their own sets of rules. To have absolute freedom when passing traffic the underlying protocol should be fully encrypted and probably even hide the source and destination IP address and port. This is a very tough problem to solve technically because you have to know the destination IP to efficiently route a packet.

keepmesmall 8y ago
The destination IP could be hidden opportunistically? Send the destination IP for high-priority requests and retry without the destination. Low-priority/long-latency requests would always hide the destination. ... I can't articulate why, but I feel even this introduces a very large amount of hidden complexity. It solves efficient routing and freedom in part, but does not consider privacy.
- solotronics 8y ago
  I don't see how you can hide destination IP. Each router has to know the destination IP to determine where to send the packet, yes there are some cases such as MPLS/VXLAN/v4VPN where the packet is encapsulated inside more routing info but for it to get to its destination the routers have to have an IP.
  - keepmesmall 8y ago
    If the routers have public keys it's possible, then the client has to determine (some or all points on) the route. I think future protocols will track use and payment via client-provided keys which are somehow linked to their ISP.

jandrese 8y ago

Of course for this reason QUIC is sometimes blocked outright in organizations that deploy those TCP middleboxes.