LWN: Comments on "QUIC as a solution to protocol ossification"

UDP abuse

excors — Tue, 20 Feb 2018 02:07:26 +0000

WebRTC uses SCTP for data channels (arbitrary user-defined data that goes alongside the standard video/audio), but it's tunnelled over DTLS over UDP, so I'm not sure where that fits in this argument.

UDP abuse

flussence — Tue, 20 Feb 2018 00:34:55 +0000

I've managed to get IPv6 traffic to work across the internet (in spite of my ISP) with a lot of persistence, but for all the good things I heard about in SCTP I've never encountered anything that supports it. Are there any examples of use in the wild?

QUIC as a solution in my firewall currently

TRS-80 — Fri, 09 Feb 2018 15:18:28 +0000

Well, if you can stop our parents being rich enough to hire lawyers in the case that little Johnny sees something inappropriate using school-provided technology, I'm sure I can update our risk matrix to obviate the need for the web filter. If they do it on parent-provided technology, that's then their problem, not ours.

QUIC as a solution to protocol ossification

kronat — Fri, 09 Feb 2018 11:32:10 +0000

It is worth to read, in their entirety, all the comments above.

My opinion on that starts from the same base as nim-nim: Google has the control of the services, Google has the control of the providing node (servers/cloud nodes), Google has the control of the most used OS (Android) and the most used Web Browser (Chrom{e,ium}).

Even committing something in the Linux networking stack is difficult, if it is not proven that it will not harm Google's use case or server performance or it does not work well with Gigabit and Gigabit of load (see for instance all the development made on TCP, perfectly fine for wired networks, but that have a performance problem on WiFi cards*).

Is it not worrying, at least?

* This will probably be solved in next release after years of not caring.

UDP abuse

flohoff — Fri, 09 Feb 2018 09:44:11 +0000

I dont think "abusing" UDP for building higher layer protocol abstraction is the way to go. Yes - fixing the "internet" to support a new IP type is hard, as was introducing IPv6 or SCTP.

Using an abstraction on top of UDP will only bring the firewall admins to drop/block those connections. You'll gain nothing. Hell - FW admins still block ICMP for no good reason because it seems unnecessary.

So do it right from the beginning and define a new protocol.

QUIC as a solution to protocol ossification

ras — Fri, 09 Feb 2018 01:46:40 +0000

> All to make sure it can work through middleboxes that horribly break everything but HTTPS.

I was at the talk, and yet he did hammer on and on about middle boxes. It sounded over the top until he said something along the lines of:

"The only fix is to encrypt everything. We had one byte, just one byte that wasn't encrypted. Then we when changed it, and we started getting reports of broken connections. It has only been out for a few months, and it wasn't published anywhere so no one could have known what that byte was. Yet ossification has set in."

At that point started to feel sorry for him.

QUIC as a solution to protocol ossification

Wol — Thu, 08 Feb 2018 18:34:04 +0000

And it seems quite clear to me that nim-nim THINKS that the owner of the middle box should control the middle box. Except it's also quite clear that the person who *really* controls the middle box is the box vendor, who over-rides the owner's changes.

And the hilarious thing is that the middle box's job is to transmit the customer's data - which it is clearly and blatantly failing to do!

What Google wants, and (maybe slightly altered) what everyone else wants, is for whatever leaves my *source* network should get to my *destination* network INTACT and UNALTERED. What f'ing right does the TRANSPORT network have to interfere and alter my data or throw it away? Because that's what nim-nim is advocating - let the transport network (and indeed, not even that, let the vendors of the equipment running the transport network) dictate what traffic is allowed is allowed to pass over the transport network. NOT good if I'm paying for my data to be transported ...

Cheers,
Wol

QUIC as a solution to protocol ossification

karkhaz — Thu, 08 Feb 2018 01:36:49 +0000

Although I'm sorry for your frustration, I must say that reading these tirades has given me a good chuckle. Thanks for sharing your experience :-)

QUIC as a solution to protocol ossification

tialaramex — Wed, 07 Feb 2018 19:33:34 +0000

Since I wrote the earlier piece, the application I'm responsible for broke again. Senior management were upset and wanted to make sure I knew about it (I work from home, so you can't physically collar me, being aggressively angry doesn't work very well over a video conference either, it just sort of looks comical but you can send loads of email, and they did), they had been told very clearly that the problem was definitely with my application. Users, including our customers and our own in-house agents were unable to use the system, frequently running into an error message, versions of which have now been emailed to me as JPEG screenshots, PDF documents, and other formats over the last several days. The error message isn't mentioned in any official documentation, and the strings from it aren't in any of our source or libraries. But there are mentions in forums found with Google. All of them end up, often after a considerable wild goose chase, pointing at a particular middle box vendor.

So I explained, calmly, that this is undoubtedly caused by a middle box, I specified the exact brand of middle box they'd most likely bought which causes this error, and that I had previously _emphatically_ warned those implementing the latest middle box that it would likely cause serious problems unless its rules had been appropriately hand-crafted to let our actual traffic through, at which point it would simply be dead weight. I think I even forwarded the emails where those responsible had promised to co-operate with me during installation, and then gone silent.

I was assured that even if we had coincidentally just bought a middle box from the exact manufacturer I specified, the network engineering team responsible were 100% certain that it wasn't their box at fault. The problem must be in my application and I needed to pull my finger out and fix whatever it was. I reiterated that it's the middle box, and suggested means by which they could verify that for themselves, and then I just let it all slide by, because it's futile to engage with such nonsense.

This morning my Product Owner, who for his sins does have to actually sit there in person and listen to this every day, managed to persuade someone to do him a favour and try a simple A/B test. He would fail to get into the application, they would switch off the middle box, then he'd try again. To their astonishment it suddenly worked. Then they switched it back on, his application session failed almost immediately and he wasn't able to get back in. How about that?

Now, nim-nim has explained elsewhere that despite symptoms like these in their opinion it's wrong to blame the middle box. Blame client software, or policy decisions, or Google. Here's the problem even if you want to sympathise with that point of view: Nobody cares. You can fire me and get another team in and re-write the entire application, spending millions of dollars and refunding all the existing customers, and at the end it still doesn't work. Or, you can switch off the middle box and it works immediately. It's a no brainer. It wouldn't even matter if _somehow_ the middle box isn't really the "cause" of your problem: no middle box, no problem.

QUIC as a solution to protocol ossification

pizza — Tue, 06 Feb 2018 19:16:03 +0000

> They can also be actively malicious while middleboxes usually aren't.

The level of operational maliciousness is often a matter of how the middlebox owner has configured things.

QUIC as a solution to protocol ossification

jezuch — Tue, 06 Feb 2018 18:53:21 +0000

Sure, endpoints can be lazy and irresponsible too - and often are! They can also be actively malicious while middleboxes usually aren't. But the endpoints can be (comparably) easily replaced or fixed. Middleboxes can't. And that's why there's so much bad feelings towards them: we all can see a problem that's easily fixed but we can't fix it. That's frustrating.

QUIC as a solution to protocol ossification

immibis — Mon, 05 Feb 2018 05:14:45 +0000

I don't believe IP multicast can scale to the Internet; every router would need to know about every multicast stream passing through it. This creates major political issues. It does work when all routers and endpoints are under the same owner so they can fix the problems instead of blame-shifting.

bad smells

immibis — Mon, 05 Feb 2018 05:11:44 +0000

I agree. I only lament that I can't run my own middlebox for my personal devices.

But that's the way it has to be - otherwise how would my phone know that my middlebox is valid, and the NSA's middlebox isn't? (Perhaps I explicitly allow it - but then they just blackmail you by cutting off your Internet service entirely if you don't approve the NSA middlebox)

QUIC as a solution to protocol ossification

immibis — Mon, 05 Feb 2018 05:10:53 +0000

Unfortunately there's no way to win.

As a user I want my traffic to be able to be accessed at 2 or 3 points:
* The service I am accessing
* The endpoint I am accessing it from
* Any intermediary device of my choosing

(note that the service may consist of multiple intermediary devices if it wants to; it's a black box from my PoV)

But my ISP would love for it to be:
* The service I am accessing
* The endpoint I am accessing it from
* Any intermediary device of their choosing

And my company that provided the endpoint (hypothetically) would also like it to be:
* The service I am accessing
* The endpoint I am accessing it from
* Any intermediary device of their choosing

If we can't have any middleboxes whatsoever, then we get:
* The service I am accessing
* The endpoint I am accessing it from

That's bad because now I can't see what my client app is actually doing.

But on the other hand, if anyone can add middleboxes (as is the case today) then we end up with:
* The service I am accessing
* My company's ISP's middlebox that breaks stuff
* My company's middlebox that breaks stuff
* My company's ISP's middlebox that breaks stuff
* My ISP's middlebox that breaks stuff
* My own middlebox that breaks stuff
* My endpoint

which is a huge mess and there's no way to run a new protocol without upgrading 4 different middleboxes owned by different people - good luck with that - this is why everything is tunneled over HTTP these days!

I can imagine a solution where users have to explicitly permit middleboxes. But then we'll still end up in the same situation as today. Give someone a choice between "press this button" or "have no Internet" and they'll press the button. And it's not their fault for being stupid; you'd do that too, it's not like you *really* have a choice. You can't even scare them away with big warning messages - "Oh, all my traffic may be spied upon by "US Internet Gateway"? I mean I guess that's necessary for the system to work. After all, it stops working when I turn it off."

Any such system will trivially allow your ISP to block all your traffic that doesn't pass through their middlebox. This can only be prevented if they don't have the option to do it in the first place. But that would mean you don't get to install *your* middlebox either. That's why it's a no-win tradeoff.

QUIC as a solution in my firewall currently

Cyberax — Sun, 04 Feb 2018 03:59:22 +0000

My brother's daughter recently went to China for a school exchange program. The first week or so her parents were only getting email updates to a non-Google address. Then she re-appeared on Facebook and Gmail - local kids in China had shown her how to work around blocking.

This is how effective Internet blocking is against determined teenagers.

I understand that people still have to go through motions and pretend that precious little children are totally "protected" by filters. But I'm not seeing why this should be made any easier. It'd be good to stop this hypocrisy fest eventually.

QUIC as a solution in my firewall currently

TRS-80 — Sat, 03 Feb 2018 05:27:09 +0000

Phones are not allowed in the classroom, and we tell parents not to give their students data access, or install a filter on it. Either way, you can't do proper blocking on an iOS, the only good solutions are an explicit proxy or always-on VPN, at which point we're back to middleboxes so you may as well do it transparently.

QUIC as a solution to protocol ossification

lsl — Fri, 02 Feb 2018 23:57:25 +0000

> There has been a lot of good work in recent years on what should be expected from home routers. With specifications so you can show your hardware is out of spec (to return it/reject supporting it if you are the ISP) and the multiple addresses of IPv6 we may see some deossification.

Having such specs available is very nice. Is there anything like it for non-home enterprise firewalls and the like?

It would be even more awesome to have some kind of test suite that admins could run when evaluating such devices. Or that you could use to help admins bring their network to a more sane state. Often times, such issues are just the result of a botched configuration with network operators unaware of the implications but happy to fix when pointed out to them.

I might even write such test suite myself if it doesn't exist yet. But what do you test for? Obvious candidates would be things like the very helpful RFC4890 ICMPv6 firewalling recommendations. Then probably test the effects of various TCP options, IP multi-cast, the proper functioning of PMTU discovery or interaction with very recent TLS and exotic features of older plaintext protocols including HTTP.

What are the other areas middlebox vendors have proven themselves incapable of implementing in a sane way? Where to expect problems?

If anyone has pointers to relevant resources, I'd be very happy to read them.

QUIC as a solution to protocol ossification

lsl — Fri, 02 Feb 2018 23:20:03 +0000

I'd love to get some examples for this. I can see how that it be convenient for lazy developers to dismiss potential issues in their programs with "the network is crap". It shouldn't be that hard to prove them wrong though, should it? So how are they blocking the resolution of the issue?

QUIC as a solution to protocol ossification

lsl — Fri, 02 Feb 2018 23:10:58 +0000

> 2. I *have* tried to work with anti-middleware persons to get them fix their implementation of some standards. Their bugs were causing pain to tends of thousands of people that had no beef in the middleware vs non middleware dispute and probably though IT people were collectively dangerous imbeciles. Only to meet obfuscation and evasion, and finally understand the breakage was 100% intentional and they were crippling some use cases and wasting their user's (and sometimes customers') time and energy to push their opinions. Only they would not own up to it and were lying to their users in pretending they had implemented standards when they had sabotaged the parts of them they didn't like, and used it as argument to propose the removal of those parts.

Some specifics would be nice. Are we really talking about bugs or about things like not implementing plaintext downgrades on encrypted protocols? Or making it harder to perform MITM attacks on TLS users thus breaking the "use cases" of ad/garbage injection (loved by mobile ISPs) and other integrity/confidentiality violations of traffic intended to be encrypted and authenticated?

QUIC as a solution in my firewall currently

Cyberax — Fri, 02 Feb 2018 18:53:18 +0000

> Perhaps, but they are students and I have a duty of care to protect them from the worst parts of the internet, therefore a there is a middlebox between them and it.
And then these students get their smartphones and jump right into the worst parts without anyone wiser...

If you do have to comply with such laws, you can install blockers directly onto the endpoints rather than on midpoints.

QUIC as a solution in my firewall currently

TRS-80 — Fri, 02 Feb 2018 17:46:47 +0000

Perhaps, but they are students and I have a duty of care to protect them from the worst parts of the internet, therefore a there is a middlebox between them and it. Is QUIC becoming used outside of Google anyway?

The middlebox we use doesn't currently support ECDHE, so I doubt TLS 1.3 support will be on the cards any time soon either. That will be a big ossification point as well due to how middlebox unfriendly TLS 1.3 is.

QUIC as a solution in my firewall currently

nybble41 — Fri, 02 Feb 2018 16:18:55 +0000

> I explicitly block QUIC at work because I can't inspect it.

That works for now because there is a fallback in place, so most sites continue to work (albeit more slowly) despite blocking QUIC. As QUIC becomes more popular, however, and incidences of brokenness diminish, that fallback ought to be phased out. At that point you will no longer be able to block QUIC without cutting yourself off from most of the Internet—and with the end-to-end principle restored, there will be much rejoicing among those trapped behind your overbearing middleware.

bad smells

Cyberax — Fri, 02 Feb 2018 07:20:31 +0000

Stay focused and stop rambles.

In case of network, the way to fix middleshitboxes is to make them impossible. There's no other way. This means encrypting protocols, making sure there are no fixed bits in the "unused" headers, adding confusing options as a part of normal workflow, etc.

QUIC as a solution in my firewall currently

TRS-80 — Fri, 02 Feb 2018 03:52:41 +0000

Ah, but then I can then MITM and block it. I explicitly block QUIC at work because I can't inspect it. deal_with_it.gif

QUIC as a solution to protocol ossification

jschrod — Fri, 02 Feb 2018 00:44:52 +0000

> nim-nim has simply insisted they're wrong, which I guess is brazen enough that it must feel righteous, like insisting "I'm the least racist person you'll ever meet" in the middle of doing something very racist.

To associate a poster on lwn.net with racism because you disagree with him is not the style of discussion that I'm used to, here around. Please refrain from it. This kind of personal attack doesn't help to communicate your arguments, either.

FWIW: I neither follow nim-nim's opinion nor yours, so please don't accuse me of bias.
excors made a good point in a neighbouring post of yours: https://lwn.net/Comments/745923/

QUIC as a solution to protocol ossification

jgknight — Thu, 01 Feb 2018 14:06:31 +0000

Definately for security appliances. Inspecting packet headers, checksums, options/flags, etc is one of the many steps these devices take to determine if something is legitimate traffic or attack/bad traffic.

Unfortunately as protocols evolve and add options, and as security device software is updated, the businesses/ISPs running these boxes tend to not upgrade until absolutely necessary. So sometimes us vendors of middleboxes are fixing/updating our software to allow new protocols or options, but the businesses/ISPs aren't upgrading.

bad smells

nim-nim — Thu, 01 Feb 2018 10:34:14 +0000

So, your solution is too let problems spread as much as possible, and avoid any remedial, till the perfect long-term solution is implemented?

I suppose you're also happy to have your bank let hackers empty your accounts, while they work on the better system that will secure everything next year?

QUIC as a solution to protocol ossification

Cyberax — Thu, 01 Feb 2018 06:37:34 +0000

But you don't need prefix delegation for IPv6. For example, iOS simply bridges the tethered WiFi with the LTE interface.

QUIC as a solution to protocol ossification

Cyberax — Thu, 01 Feb 2018 06:34:10 +0000

> Anyone who wants to understand the complexity of setting up an end-to-end connection between two arbitrary computers on the internet I suggest you look at RFC5245 Interactive Connectivity Establishment (aka ICE). This is being deployed in WebRTC so that video chat will work in browsers, and is much of magic the skype used back in the day to not require server resources.
Around 2007 I was involved in a project that used multiple HTTP connections to transmit VoIP packets, with forward error correction and elaborate TCP retry avoidance logic. All-in-all, it took about several man-years to get right.

All to make sure it can work through middleboxes that horribly break everything but HTTPS.

Good luck trying to write the same code if you're a small company. But meanwhile, nim-nims can enjoy "control" that they exert by breaking Google.

QUIC as a solution to protocol ossification

mtaht — Thu, 01 Feb 2018 04:13:19 +0000

regrettably problems with address subassignment (e.g dhcp-pd) are making tethering via ipv6 hard, on most cellphones. You might be getting ipv6 on the phone outside, but not inside.

I shure hope "5g" deployments get this right.

QUIC as a solution to protocol ossification

ebiederm — Thu, 01 Feb 2018 01:45:16 +0000

Partly this is simple the impatience of people wanting to deploy something that works everywhere now.

Partly this is PNAT firewalls that everyone calls wireless routers in their homes. The fact they are sharing a single IPv4 address among multiple computers means for protocols to work at all they have to look past the IP layer into the TCP/UDP layer and give some ports to some machines and other ports to other machines.

There has been a lot of good work in recent years on what should be expected from home routers. With specifications so you can show your hardware is out of spec (to return it/reject supporting it if you are the ISP) and the multiple addresses of IPv6 we may see some deossification.

But even then there are only 1 byte's worth of protocols that sit above IP. Which unfortunately means that protocol numbers must be assigned with care. Which means that if you don't have something that is a fantastic improvement over what has gone before getting a protocol number will be work, and getting everyone to support it will be a huge uphill struggle.

Anyone who wants to understand the complexity of setting up an end-to-end connection between two arbitrary computers on the internet I suggest you look at RFC5245 Interactive Connectivity Establishment (aka ICE). This is being deployed in WebRTC so that video chat will work in browsers, and is much of magic the skype used back in the day to not require server resources.

When you honestly need PNAT in every home, and you consider implementation bugs. It becomes increasingly clear new protocols need to be encrypted just so that in some small fraction of cases they are not mistake for something else, and broken by someones well meaning but buggy code.

Then you get the challenge that most protocols get deigned on nice networks that don't run NAT of any kind. There are no obstructions. So the protocol designers don't make their protocols deal with the reality of the internet. SCTP is a good examples of that. Linux to this day does not have a good PNAT solution for multi-homed SCTP because the design of SCTP makes it essentially impossible unless you can see all traffic on of the paths (and machines are not multi-homed behind you if you can see all of the traffic they emit). Which means that even if someone wanted to add support for SCTP to the next generation of a NAT box it isn't easy.

If you are willing to live with not supporting the small fraction of problem cases, and have enough pull to get people to fix their broken networks you can see that things are not completely ossified. The increasing percentage of internet clients with IPv6 support is proof of that. The larger address space really is worth dealing with the mess.

So the ossification picture is not quite a bleak as some people make out. Progress is possible when it is important enough. But it is hard to design a new protocol, and it even more so with the prevalence of PNAT on the internet. The best hope for reduced ossification is the deployment of IPv6 which will mean middle boxes should be both more standardized, and have much less reason to mangle the traffic going through them. As the prevalence of addresses in IPv6 removes the need for PNAT.

QUIC as a solution to protocol ossification

excors — Wed, 31 Jan 2018 16:19:40 +0000

It sounds like there's disagreement about "endpoints should have control, not the network(/middleboxes)" vs "the network should have control, not endpoints" - but I think they're both derived from the same starting point of "competent people should have control, not incompetent people".

There are problems caused by incompetence on both sides - e.g. everyone can (and does) fail to implement standards correctly. Competent people working on endpoints can easily fix any problems on their side but will suffer badly from problems in the network. Competent people working on the network can easily fix any problems on their side but will suffer badly from problems in the endpoints. Everyone will tend to overestimate the level of incompetence in the other side, because that's what they spend most of their time fighting against. And since they are themselves competent, it's quite reasonable for them to say "it would be better if I was in control of everything". But that leads to contradictory conclusions from the two sides.

It would be nice if competent people *were* in control, but I have no idea how to achieve that without some authority to decide who is competent and to give them control over everything (which may be possible within a data center but not for the global internet). I suppose the endpoint people will win eventually regardless of merit, because it'll reach an equilibrium state when all traffic is encrypted and indistinguishable so middleboxes can't do anything.

(Incidentally, I don't mean to insult specific people as incompetent - they might have been perfectly competent a decade ago and e.g. designed a system that everyone agreed was brilliant at the time, but that now turns out to be fatally flawed because we judge it by new criteria. That's not their fault, but the effect is the same.)

bad smells

tialaramex — Wed, 31 Jan 2018 14:47:30 +0000

My mother bought a new house, it has a big downstairs shower which the previous owners had installed during their remodelling. I visited her the day after she took possession, nice place. Any way, some months later I visited again, and this downstairs shower room now had a powerful scent dispenser, spraying masking scent into the air every minute or so. It smelled awful, a mix of the scent and some powerful but unpleasant smell that was hard to name.

I asked my mother about it, and she told me she had to fit the dispenser because the smell was so awful. She had never used the shower, and rarely went in there, but even just in passing she would notice the smell, so she felt she had to "do something" about it.

Bad smells don't magically appear from nowhere, and a masking scent won't fix them. I filled a cup with water and poured it into the shower drain. My mother was astonished that within hours the smell went away, I switched off her dispenser and went home. Showers have drains, which in most homes are piped into the black water sewage output, via a U-bend to trap unpleasant smells from the sewer system. If the U-bend dries up, sewer gases leak into your home which can smell bad and in rare cases even be directly dangerous. Unused drains should be removed, but if you don't want to remove a drain, just rinse it through periodically, no need for more than a cup or so of water, and it'll be fine.

What you've got is an attempt to mask the bad smell from terrible people problems in your organisation.

QUIC as a solution to protocol ossification

nim-nim — Wed, 31 Jan 2018 12:50:09 +0000

I used to think it was wholly the middle box manufacturer fault too… until investigation showed up than in many cases the network client contributed to the problem, and would block any resolution, all the while blaming the middle box.

QUIC as a solution to protocol ossification

jezuch — Wed, 31 Jan 2018 11:21:11 +0000

I don't really care what Google wants. Maybe even they want the same thing as me: SCTP that can be used, IP multicast (that was in the standard forever) that can be used etc etc. I completely agree that control is needed but right now the default is to break everything the middle box manufacturer doesn't care or know about. It's just lazy and irresponsible.

QUIC as a solution to protocol ossification

nim-nim — Wed, 31 Jan 2018 09:41:08 +0000

I buy middleboxes that advertise 'restrict network access of developers that can't be bothered with reading security 101 books, do not test what happens when their software is misused, do not feel responsible because cleaning up breakage is a non-dev task, will claim anything is a network or server problem since no one knows who runs those, and by the time others have wasted energy checking infra runs as designed will have moved to breaking some other part of their software'.

The kind of guys that hardcode admin/admin backdoors in their software because that enables them to silently fix their mistakes without owning up to them and asking for permission to access and modify production systems they should never touch. And it's "secure" because no one knows the backdoor is there, right?

QUIC as a solution to protocol ossification

nim-nim — Wed, 31 Jan 2018 09:30:53 +0000

Just to be clear:

1. I don't sell and I haven't ever sold not ever benefited from any middlebox sell, directly or indirectly

2. I *have* tried to work with anti-middleware persons to get them fix their implementation of some standards. Their bugs were causing pain to tends of thousands of people that had no beef in the middleware vs non middleware dispute and probably though IT people were collectively dangerous imbeciles. Only to meet obfuscation and evasion, and finally understand the breakage was 100% intentional and they were crippling some use cases and wasting their user's (and sometimes customers') time and energy to push their opinions. Only they would not own up to it and were lying to their users in pretending they had implemented standards when they had sabotaged the parts of them they didn't like, and used it as argument to propose the removal of those parts.

3. In any medium to large organization you will have idiots that will do things just because they can and feel they will get away with it. That's what control systems are about. If you don't believe in control systems, share a computer with a score of other persons, all running as admin, with no enforcing at all, and see how long you can cope with being charged with making the thing run.

4. If you think software developers are any more responsible just look at the junk that get pushed to app stores and all the nasty permissions those apps ask for just because app stores were designed with a "no middle control" mindset and the few controls that exist were bolted on later and are completely inefficient and lacking. Networks are no magic, they're an IT system like a computer, they have the same control requirements (and will need more as they migrate to SDN. More power means more responsibility, more responsibility means more control requirements).

5. Disabling controls makes things run faster and simpler. Who would have thought of it? (see also: Intel/meltdown)

6. In a "smart object" world where everything from microwaves to lightbulbs runs IP you *will* have to administer a fairly complex network at home. We'll see how much you like it when Google strips you of any control power, and known-dangerous and unpatched gadgets get to talk freely with the exterior. I believe smart camera operators had their first waking call last year.

I'll leave you the 'amusing' insults that have really no place on lwn.

QUIC as a solution to protocol ossification

willy — Wed, 31 Jan 2018 00:45:42 +0000

There are a number of other protocols developed over the years which never made it, mostly because of middlebox throttling. DCCP is one, and plan9 developed Internet Link for a similar purpose.

QUIC as a solution to protocol ossification

gdt — Tue, 30 Jan 2018 23:55:30 +0000

There's a non-technical aspect as well. Even having a small proportion of the Internet become uncontactable is billions in forgone revenue for an advertiser like Google. Part of protocol ossification is an unwillingness to say "well it just won't work that that 0.5% of sites". Poor code has always been a problem, but the changed economics means that this code now wags the dog.

QUIC as a solution to protocol ossification

Cyberax — Tue, 30 Jan 2018 21:21:47 +0000

> The "ossification" Google harps on is someone else exercising some form of non-Google control
I guess you buy middleboxes that advertise: "Breaks VoIP connections better than any other competitor!" or maybe "Drops random TCP connections based on ECN flag!"

Right?