|
|
Subscribe / Log in / New account

QUIC as a solution to protocol ossification

QUIC as a solution to protocol ossification

Posted Jan 31, 2018 12:50 UTC (Wed) by nim-nim (subscriber, #34454)
In reply to: QUIC as a solution to protocol ossification by jezuch
Parent article: QUIC as a solution to protocol ossification

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.


to post comments

QUIC as a solution to protocol ossification

Posted Feb 2, 2018 23:20 UTC (Fri) by lsl (subscriber, #86508) [Link]

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

Posted Feb 6, 2018 18:53 UTC (Tue) by jezuch (subscriber, #52988) [Link] (1 responses)

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

Posted Feb 6, 2018 19:16 UTC (Tue) by pizza (subscriber, #46) [Link]

> 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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds