News for hackers. Stuff that matters.
Re:Working Group Last Call: QUIC protocol drafts by 1_player on Wednesday June 10, 2020 @11:08AM (#23477870)
Why would network providers have to fix their network? Why 5 years to adopt?

HTTP/3 and QUIC are based on UDP. This is very different to the IPv6 transition.

Re:Working Group Last Call: QUIC protocol drafts by cg505 on Wednesday June 10, 2020 @11:48AM (#23478429)
There are a ton of networks (think big corporate networks, schools, shared apartment wifi) that enforce too many weird port restrictions. Many of those places rarely get network or config updates. I don't think it's as bad as IPv6, but there are a lot of people for whom it isn't going to just work out of the box.
Re:Working Group Last Call: QUIC protocol drafts by dathinab on Wednesday June 10, 2020 @02:39PM (#23480549)
Sure, but for that people a non small part of the internet is already broken. Like websockets being broken and in turn slack being broken.
Re:Working Group Last Call: QUIC protocol drafts by patrickmcmanus on Tuesday June 16, 2020 @10:15AM (#23539371)
websockets is carried on TCP. Often bootrstapped on HTTPS tcp/443.
Re:Working Group Last Call: QUIC protocol drafts by tyingq on Wednesday June 10, 2020 @02:39PM (#23480552)
"Network providers" isn't really the issue. It's all the corporate and school networks that block UDP, or run broken spyware MITM boxes, etc. Chrome has to do a TCP vs UDP race to figure out if UDP connectivity to the internet is broken.
Re:Working Group Last Call: QUIC protocol drafts by kitteh on Wednesday June 10, 2020 @03:26PM (#23481024)
In some cases it is the ISPs. I'll share an example:

Some broadband ISPs struggle with the fact that their customers get compromised and join botnets. Over the last few years UDP has become the ddos attack of choice. Broadband access networks struggle with how to mitigate this. Some try to block the command and control (C2) and some try to go the customer outreach angle. For example, notifying them that they have a compromised machine or putting them in a walled garden with a website that pops up telling them they've been impacted. The problem is that outreach is costly and not super effective. So they found another option: apply throttles on UDP. A few have done this and it's led to big problems because from a user experience QUIC works enough - and then falls apart.

Some of the access providers have changed the throttles to be less aggressive while others have resorted to being aggressive on the topic ("you should have made a new protocol and consulted with us!").

Re:Working Group Last Call: QUIC protocol drafts by zozbot234 on Wednesday June 10, 2020 @11:24AM (#23478100)
We might want to have a SCTP-based HTTP/4 down the road. That would surely benefit from some fixes on the network side.
Re:Working Group Last Call: QUIC protocol drafts by jeffbee on Wednesday June 10, 2020 @11:30AM (#23478171)
See, that will NEVER happen. Completely impractical. SCTP has a different protocol number in the IP datagram header and many devices will either drop or malfunction when faced with protocol numbers they don't understand. UDP and TCP (protocol numbers 6 and 17) are well-supported, by practically all devices.
Re:Working Group Last Call: QUIC protocol drafts by anticensor on Wednesday June 10, 2020 @11:35AM (#23478250)
Why not package QUIC in IP directly without UDP in between?
Re:Working Group Last Call: QUIC protocol drafts by jlouis on Wednesday June 10, 2020 @12:57PM (#23479324)
UDP is as clean as you can get it. It is more or less free of any overhead. And networks know UDP already. A new IP protocol is far more likely to be rejected in the network.
Re:Working Group Last Call: QUIC protocol drafts by tptacek on Wednesday June 10, 2020 @04:18PM (#23481583)
This, exactly; it's the actual reason UDP exists. It's a design smell for anything to ask for a new IP protocol number.
Re:Working Group Last Call: QUIC protocol drafts by sagichmal on Wednesday June 10, 2020 @11:43AM (#23478379)
A protocol separate to UDP and TCP altogether would suffer from middlebox interference problems.
Re:Working Group Last Call: QUIC protocol drafts by anticensor on Wednesday June 10, 2020 @11:53AM (#23478504)
Aaaa, you mean the problem of -smart- stupid pipes. These do and will exist all the time and this is an opportunity for them to realise how detrimental they do is to Internet.
Re:Working Group Last Call: QUIC protocol drafts by sagichmal on Wednesday June 10, 2020 @07:20PM (#23483330)
They're inextricably woven into the fabric of the internet, and unfortunately can't be wished away.