101–110 of 116 posts
Earlier quoted context omitted.
SCTP is really cool, I first found out about it because it’s the basis for WebRTC data channels. It’s basically reliable UDP, but you can turn off the reliability if you want. Makes me wonder why QUIC exists when SCTP does…
> why QUIC exists when SCTP does Because QUIC uses UDP, which is supported by most/all intermediate routing equipment.
You don't need to make up your own for this experiment. There's already a pretty old protocol that's far superior to TCP, but failed to get adoption because of network hardware dropping everything other than TCP and UDP. It's called SCTP.
SCTP is really cool, I first found out about it because it’s the basis for WebRTC data channels. It’s basically reliable UDP, but you can turn off the reliability if you want. Makes me wonder why QUIC exists when SCTP does…
QUIC is supposed to be faster than SCTP by combining layers and eliminate round trips. Also, QUIC is a stream protocol like TCP. SCTP makes messages explicit. Both have multiplexing which is why seem different.
Earlier quoted context omitted.
Yes I know why netops want to block QUIC but that just shows the tension between the folks who want to build new functionality and the folks who are in charge of enterprise security. I get it, I've held SRE-like roles in the past myself. When you're in charge of security and maintenance, you have no positive incentive to allow innovation. New functionality gives you nothing. You never get called into a meeting and co…
Possibly even SRE shouldn't even exist, not only the structural issues you mention, but... If you approach to security is that only square tiles are allowed because your security framework is a square grid, and points just break your security model, maybe it was never a valid thing to model in the first place. I'm not saying security should not exist, but to use an analogy the approach should be entirely different -…
Earlier quoted context omitted.
I understand that, but what I'm replying to says: "TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup."
RFC6177 specifically recommends a /48 to /56 because future security measures may require subnetting, even on home networks (eg having IoT devices on a secure DMZ). Basically, giving out a /64 is the modern equivalent to ISPs saying "you have to pay extra to have more computers on the internet and you're not allowed to use NAT" that was actually a thing up until the mid 2000s. The frustrating this is that there's no…
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Not following recommendation from RFC6177 by allocating a perfectly valid /64 (it being inconvenient to some is another story) is not "violates the documented standards"
Earlier quoted context omitted.
> That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted. Of course there is. Blocking all traffic with destination port 443 is virtually impossible. Conversely, blocking port 853 is trivial, and it forces all clients to either not resolve DNS, or downgrade to un-encrypted DNS. Of course, if DoH had n…
You've sidestepped my point and merely reiterated yours. Both DoH and DoT achieve actual concealment (and therefore privacy and censorship avoidance) through encryption. That one is more obscure than the other doesn't change the fact that the whole point of both protocols is encrypted DNS queries, not obscured DNS queries. And again, if I'm the network operator and a host can obscure/obfuscate its DNS queries, then I…
You're mostly commenting on the negative effect that DoH has over a private network administrator's legitimate need to control DNS resolution in their own private network.
I was discussing how DoH has positive effects on a network user trying to evade illegitimate control over their DNS resolution on the Internet, such as legally enforced DNS-based censorship of certain sites. Several countries have legally mandated ISPs log and prevent resolution of, say, thepiratebay.com; and some include a requirement to prevent attempts at circumvention of these bans, such as DoT traffic (they might also ban DoH traffic to well known resolvers, which is where own proxies come in).
Regardless, I think we can both agree that DoH was not created to work around ossification, the way QUIC was built on top of UDP instead of being a separate transport.
> I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted.
Also, this is another level of miscommunication. I agree you don't need DoH to protect from eavesdropping, DoT works just as well. DoH protects from ISPs dropping easily-identifiable DoT packets to force a downgrade to regular plaintext DNS.
Earlier quoted context omitted.
I am now genuinely wondering Maybe its me being stupid but why don't we use quic always instead of tcp? I think it has to do with something that I read that tcp can do upto 1000 connections simultaneously no worries and they won't interfere with each other's bandwidth / impact each other , but udp does make it possible for one service being very high to impact other. There was this latest test by anton putra with udp…
> Maybe its me being stupid but why don't we use quic always instead of tcp? A big reason is because QUIC is a lot younger than TCP and it will take a while for all the use cases of TCP to decide (if they are actively maintained and looking at possible upgrades) if QUIC is a good option worth testing. QUIC's rollout so far hasn't been entirely without bugs/controversies/quirks/obstacles/challenges. You still see a lo…
That is kind of nice to know actually. The support will come considering its built on top of UDP. You just need people pushing and google is already pushing it hard .
The main problem is quic's support in languages. But support will come.So after reading this comment of yours , I am pretty optimistic about quic overall
It feels like the article ends with a cliffhanger! Why did a single packet of the custom protocol get through with all later packets dropped? Does anyone know?
my guess is the first packet got through a firewall, which created a flow. subsequent packets then got blocked because the firewall has no way of matching this to an existing flow.
Earlier quoted context omitted.
> Maybe its me being stupid but why don't we use quic always instead of tcp? A big reason is because QUIC is a lot younger than TCP and it will take a while for all the use cases of TCP to decide (if they are actively maintained and looking at possible upgrades) if QUIC is a good option worth testing. QUIC's rollout so far hasn't been entirely without bugs/controversies/quirks/obstacles/challenges. You still see a lo…
so quic just lacks the decades of experience but is a better protocol than tcp overall ? That is kind of nice to know actually. The support will come considering its built on top of UDP. You just need people pushing and google is already pushing it hard . The main problem is quic's support in languages. But support will come.So after reading this comment of yours , I am pretty optimistic about quic overall
(On the diversity of implementations front: So far we've got Google's somewhat proprietary implementation, Apple's kind of broken entirely proprietary implementation, and Microsoft's surprisingly robust and [also surprisingly to some] entirely open source C implementation. General language support would be even worse without msquic and the number of languages binding to it. Microsoft seems to be doing a lot more for faster/stronger/better QUIC adoption than Google today, which I know just writing that sentence will surprise a lot of people.)
There will be trade-offs to be found with TCP. For instance, a lot of discussion elsewhere in these threads is on the overbearing/complicated/nuanced congestion control of TCP, but that's as much a feature as a bug and when TCP congestion control works well it quietly does the internet a wealth of good. QUIC congestion control is much more a binary: dropped packets or not. That's a good thing as an application author, especially if you are expecting the default case to be "not" on dropped packets, but it doesn't give the infrastructure a lot of options and when pressure happens and those "allow UDP packet" switches are turned off and most of your packets as an application developer are dropped how do you expect to route around that? At least for now most of the webservers built to support HTTP/3 still fallback to HTTP/2 on request, go back to the known working congestion control of TCP that most of the internet and especially the web was built on top of.
I'm not a pessimist on QUIC, I think it has great potential. I also am not an optimist about it 100% replacing TCP in our near future, and maybe not even in our lifetime. As an application developer, it will be a great tool to have in your toolbelt as a "third" compromise option between TCP and UDP, but deciding between TCP and QUIC is probably going to be an application-by-application pros/cons list debate, at least in the short term and I think probably in the long term too.
Earlier quoted context omitted.
Yes this is called protocol ossification [1] or ossification for short. Other transport layer protocol rollouts have been stymied by ossification such as MPTCP. QUIC specifically went with UDP to prevent ossification yet if you hang out in networking forums you'll still find netops who want to block QUIC if they can. [1]: https://en.m.wikipedia.org/wiki/Protocol_ossification
> Other transport layer protocol rollouts have been stymied by ossification such as MPTCP AFAIU, Apple has flexed their muscle to improve MPTCP support on networks. I've never seen numbers, though, regarding success and usage rates. Google has published alot of data for QUIC. It would be nice to be able compare QUIC and MPTCP. (Maybe the data is out there?) I wouldn't presume MPTCP is less well supported by networks…