Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google To Propose QUIC As IETF Standard

Posted by timothy on from the ok-now-do-it-this-way dept.

As reported by TechCrunch, "Google says it plans to propose HTTP2-over-QUIC to the IETF as a new Internet standard in the future," having disclosed a few days ago that about half of the traffic from Chrome browsers is using QUIC already. From the article: The name "QUIC" stands for Quick UDP Internet Connection. UDP's (and QUIC's) counterpart in the protocol world is basically TCP (which in combination with the Internet Protocol (IP) makes up the core communication language of the Internet). UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP. ... That's why UDP is great for gaming services. For these services, you want low overhead to reduce latency and if the server didn't receive your latest mouse movement, there's no need to spend a second or two to fix that because the action has already moved on. You wouldn't want to use it to request a website, though, because you couldn't guarantee that all the data would make it. With QUIC, Google aims to combine some of the best features of UDP and TCP with modern security tools.

46 of 84 comments (clear)

  1. What is wrong with SCTP and DCCP? by jd · · Score: 4, Interesting

    These are well-established, well-tested, well-designed protocols with no suspect commercial interests involved. QUIC solves nothing that hasn't already been solved.

    If pseudo-open proprietary standards are de-rigour, then adopt the Scheduled Transfer Protocol and Delay Tolerant Protocol. Hell, bring back TUBA, SKIP and any other obscure protocol nobody is likely to use. It's not like anyone cares any more.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:What is wrong with SCTP and DCCP? by Anonymous Coward · · Score: 1

      you _do_ known that SCTP was by IBM, right?

    2. Re:What is wrong with SCTP and DCCP? by Lally+Singh · · Score: 4, Informative

      SCTP, for one, doesn't have any encryption. QUIC integrates a TLS layer into it, in a way that avoids a lot of connection setup time. The best you could do in SCTP is to put it under DTLS, which won't be as fast. Second, SCTP has horrible fragmentation behavior -- NDATA was supposed to help, but didn't make it in. It uses TCP's congestion window system over the entire association, while QUIC also has pacing. And looking at RFC2960, you'll see the names: Motorola, Cisco, Siemens, Nortel, Ericsson, and Telecordia. Generally someone has to pay engineers to make the standards.

      As for the article, the UDP vs TCP discussion is a red herring. AFAICT, QUIC's use of UDP is for compatibility with existing IP infrastructure.

      --
      Care about electronic freedom? Consider donating to the EFF!
    3. Re:What is wrong with SCTP and DCCP? by WaffleMonster · · Score: 4, Interesting

      SCTP, for one, doesn't have any encryption.

      Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack). A feature QUIC does not provide.

      Managing transport and encryption in a single protocol makes the resulting system more brittle and complex. Improvements to TCP helps everything layered on top of it. Improvements to TLS helps everything layered on top of it.

      Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.

      QUIC integrates a TLS layer into it, in a way that avoids a lot of connection setup time.

      TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.

      I have yet to hear a coherent architectural justification for QUIC that makes sense... The reason Google pushes it is entirely *POLITICAL* this is the path of least resistance granting them full access to the TCP stack and congestion algorithms without having to work to build consensus with any other stakeholder.

    4. Re:What is wrong with SCTP and DCCP? by mveloso · · Score: 1

      Did SCTP have horrible behavior, or the tested implementation? The QUIC doc says nothing about that. QUIC vs SCTP is on page 8.

      https://docs.google.com/docume...

    5. Re:What is wrong with SCTP and DCCP? by Jack9 · · Score: 2

      > QUIC solves nothing that hasn't already been solved.

      Creating an IETF standard, based on a working implementation, isn't relevant to what problems it can service. While Google makes strategic and implementation mistakes, their technical research and solutions are usually quite good. The IETF is for this kind of documentation. ie Producing high quality, relevant technical documents that influence the way people design. The fact that someone might reject it as a "NotInventedHere", is not a compelling reason to avoid documenting a standard that may never be used by anyone else. More is better, in this context.

      --

      Often wrong but never in doubt.
      I am Jack9.
      Everyone knows me.
    6. Re:What is wrong with SCTP and DCCP? by Anonymous Coward · · Score: 1

      WHY NOT USE SCTP over DTLS?
      One recurring question is: Why not use SCTP (Stream Control Transmission Protocol) over DTLS (Datagram Transport Layer Security)? SCTP provides (among other things) stream multiplexing, and DTLS provides SSL quality encryption and authentication over a UDP stream. In addition to the fact that both of these protocols are in various levels of standardization, this combination is currently on a standard track, and described in this Network Working Group Internet Draft.

      The largest visible issue with using these protocols relates to our goals in the area of connection latency, and is perhaps the most critical conflicting element. In addition, we can also anticipate issues in bandwidth efficiency that may reduce our ability to achieve the goals of QUIC.

      CONNECTION ESTABLISHMENT LATENCY OF SCTP over DTLS
      One of the major and believably achievable goals of QUIC, is to predominantly have zero RTT connection (re)establishment, as was mentioned in goal 3a above. It is highly doubtful that SCTP over DTLS can come close to achieving that goal.

      The fact that SCTP and DTLS are currently implemented as layered protocols, one atop the other, already instigates an overall connection latency that is the sum of the two connection latencies. This is seen in section 5.1 of the Draft, where they note:

      A DTLS connection MUST be established before an SCTP association can be set up.

      SCTP (alone) appears to require 1 full round trip in connection establishment prior to any data transfer. See section 5 of the SCTP RFC 4960 for a discussion of this requirement.

      DTLS appears to routinely require 3 round trips in its connection establishment. DTLS is modeled after TLS, which defaults to a 2 RTT HELLO exchange at connection establishment. As noted in section 8.1 of DTLS’s description: DTLS generally uses a full 3 round trips to negotiate a connection (including cookie exchange). That section notes that the 3 round trips are comparable to a TLS over TCP connection establishment, if the TCP’s connection RTT is accumulated with the 2 RTTs for the TLS HELLO.

      As a result, with the above baseline connection round trips, we would anticipate a cost of roughly 4 round trips to establish an SCTP over DTLS connection. In contrast, we expect to be able to perform a QUIC connection establishment with zero RTT overhead. Worst case for QUIC should be one RTT overhead utilizing approaches kindred to SSL False Start. We anticipate being able to reduce the probability of that False Start case to very low levels.

      It is plausible that some of the connection overhead in SCTP over DTLS could be reduced, but it is highly doubtful that without major changes and merging of the protocols, that a competitive startup latency could be achieved, and the goals of QUIC met.

      EFFICIENT UTILIZATION OF BANDWIDTH FOR SCTP over DTLS
      The layering of SCTP over DTLS tends to make it more difficult to most efficiently utilize bandwidth in UDP packets. As an example, the SCTP transport conveys data to order packets, and data ranges. At the same time, DTLS is required to separately transport distinctive packet information in the form of cryptographic initialization vectors, used for decryption of packets. Integrated protocols, such as QUIC, can utilize the sequencing information for the stream protocol, as the basis for the initialization vector in packet decryption. The result of this integration is reduced packet overhead. We anticipate that this integration will save data space in several additional places, notably increasing packing efficiency. [TBD: We should provide specific gains, and byte counts, per packet, to fully flesh out this argument.]

      PACKET LOSS RETRANSMISSION LATENCY
      Goal 3b suggests that we should attempt to reduce retransmission latency by utilizing FEC codes. Neither DTLS nor SCTP currently have provisions for using FEC, and it would appear to be a very significant modification to try to incorporate such. There are some efforts to add FEC b

    7. Re:What is wrong with SCTP and DCCP? by Demonoid-Penguin · · Score: 1

      How about discussing the technical differences and pros & cons instead of the source then? A post below does that and is way more informative than just listing off other protocols and saying nothing about them.

      Nooooooo!! It should be decided by a house vote. Face-painters rule!

    8. Re: What is wrong with SCTP and DCCP? by Anonymous Coward · · Score: 2, Interesting

      No they don't.
      IG TLS frames are unalgned with the transport framing, then a packet loss causes a delay in the interpretation of any data of that TLS frame until the packet is recovered. The means, practically, that TLS on TCP is lots slower when there is any packet loss. .. And packet loss is fairly common, at between 1.5 and 3% on "good" networks,and far worse in placed like India.

    9. Re:What is wrong with SCTP and DCCP? by swillden · · Score: 5, Interesting

      SCTP, for one, doesn't have any encryption.

      Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack).

      I disagree. To me there's at least one really compelling reason: To push universal encryption. One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.

      But there are other reasons as well, quite well-described in the documentation. The most significant one is performance. QUIC achieves new connection setup with less than one round trip on average, and restart with none... just send data.

      Improvements to TCP helps everything layered on top of it.

      True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least. That would not only slow adoption, it would also mean a whole lot of additional design complexity forced by backward compatibility requirements. QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself. It will make its way into the OS stacks, but systems that don't have it built in will continue using it as an app library.

      Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.

      So improve and use those protocols. You may even want to look to QUIC's design for inspiration. Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.

      In the meantime, QUIC will be widely deployed, making your work irrelevant.

      As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value. A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful. Stuff always gets repurposed and sufficient re-evaluation of security requirements is rare (even assuming the initial evaluation wasn't just wrong).

      TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.

      Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.

      There was much valid (IMO) criticism of SPDY, that it really only helped really well-optimized sites -- like Google's -- to perform significantly better. Typical sites aren't any slower with SPDY, but aren't much faster, either, because they are so inefficient in other areas that request bottlenecks aren't their problem, so fixing those bottlenecks doesn't help. But QUIC will generally cut between two and four RTTs out of every web browser connection. And, of course, it also includes all of the improvements SPDY brought, plus new congestion management mechanisms which are significantly bette

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:What is wrong with SCTP and DCCP? by epiphani · · Score: 5, Interesting

      I have yet to hear a coherent architectural justification for QUIC that makes sense... The reason Google pushes it is entirely *POLITICAL* this is the path of least resistance granting them full access to the TCP stack and congestion algorithms without having to work to build consensus with any other stakeholder.

      Many years ago, in an earlier life, I tried to make changes through the IETF to an existing protocol. I was responsible for one of the major IRC servers, and still am though IRC is effectively in maintenance only. IRC is a shit protocol - really, embarrassingly bad. So I set up a conversation - grabbed the developers of all of the major clients and servers, and got us all on a mailing list to try to do something about it. We ALL knew it was bad, and we all knew it needed serious overhaul - if not a complete scrapping. We'd even fantasized about a non-tcp multipathing protocol that would be more appropriate for IRC. But like hell that was gonna happen.

      This was a group of people that, for the most part, didn't make money from IRC. It was a hobby. We had no corporate agendas, no major impacts to our livelihoods, and the only constraint to implementation was our own time. In the six months we spent, we managed to publish one draft to the IETF. It expired and we effectively gave up. Building consensus is hard, time consuming, and quite honestly not worth the effort when you're talking about this kind of thing.

      Google is in a position to just do it, and honestly, I'm fine with that. Otherwise everyone would pop up with an opinion, and nobody would get anywhere. That's why we haven't seen anything come up to rival TCP, even though TCP is pretty bad for a lot of applications.

      The only point at which I'd have a problem is if their QUIC protocol isn't completely open and free, and totally unencumbered by intellectual property constraints (patents, etc). Otherwise, go for it - and give me a protocol api/sdk in C so I can give it a shot.

      --
      .
    11. Re:What is wrong with SCTP and DCCP? by loufoque · · Score: 1

      NIH syndrome, a Google specialty.

    12. Re:What is wrong with SCTP and DCCP? by haibijon · · Score: 1

      It looks like you can already start playing in C/C++ if you want, you just need Go to build the libquic BoringSSL dependency (and there's already a discussion around trying removing Go from the build process in Issues).

      libquic: "sources and dependencies extracted from Chromium's QUIC Implementation with a few modifications and patches to minimize dependencies needed to build QUIC library."

    13. Re:What is wrong with SCTP and DCCP? by DarkOx · · Score: 2

      Working code speak volumes in the standards process and that is okay. You take on the risk that nobody will be interested in what you have built or you may discover political opposition that you never counted on; if the resistance is strong enough you get left holding the bag having spent time and treasure on something that will never see wide use.

      On the other hand if you start out with a large open consensus building process as you say its very likely you don't get anywhere, or end up with a bastardized design by committee mess, and we spend the next two decades reading on slashdot about how if only people had listened to Person about X during the design process the world would be better.

      Short answer is there are problems with both approaches and neither is right or wrong, you just have to go with what makes the most sense in terms of resources and time scale for you.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    14. Re:What is wrong with SCTP and DCCP? by rossdee · · Score: 1

      "NIH syndrome, a Google specialty."

      What has the National Institute of Health have to do with it.

      (Although I'm guessing Rick Perry will abolish it if he becomes President)

    15. Re:What is wrong with SCTP and DCCP? by loufoque · · Score: 1

      http://lmgtfy.com/?q=nih+syndr...

    16. Re:What is wrong with SCTP and DCCP? by osu-neko · · Score: 1

      ...and good for that. Bad standards arise from committees sitting around spit-balling ideas. Good standards come from committees blessing existing practices already proven in the field. Maybe you smooth out a rough spot or two, but ultimately it ought to look for the most part like what's already out there working well. "Not in scope" was precisely the right response for most of the junk people wanted to throw into HTTP/2.0. Alas, it does give people who didn't their favorite feature thrown in ample opportunity to whine. Kamp's whining has the wonderful virtue of being amusingly self-contradictory. "History has shown overwhelmingly that if you want to change the world for the better, you should deliver good tools for making it better, not policies for making it better." Exactly. Trying to improve the world by setting policy via IETF standards, though, is exactly what the IETF did not do in this case, by not adding those things he thinks should be used as a matter of course, and that's what's making Kamp so mad.

      --
      "Convictions are more dangerous enemies of truth than lies."
    17. Re:What is wrong with SCTP and DCCP? by recharged95 · · Score: 1

      Hence, whatever happened to RUDP?

      Everyone keeps turning UDP into some pseudo TCP w/o all the extras....that's what RUDP was built for.

    18. Re: What is wrong with SCTP and DCCP? by grmoc · · Score: 1

      Having seen the result of design-by-committee (i.e. design by politics instead of designing to fit a functional need), I can say that it doesn't work.

      The outcome is almost always better when the protocol has actually been implemented, the kinks worked out, and then you ask others to use it. ...You know, useful is a necessary component of reusable...
      But, if you're interested in FUD and a lack of progress instead of something which actually works, by all means do design-by-committee and get nearly useless protocols that implementers ignore.

    19. Re:What is wrong with SCTP and DCCP? by WaffleMonster · · Score: 1

      I disagree. To me there's at least one really compelling reason: To push universal encryption.

      Too bad the goal was not pushing universal security instead.

      One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.

      What we need are systems that are actually secure not ones that pretend to be. Hard to get excited about a "feature" that is worthless against most threats.

      True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least.

      Is there a technical barrier with respect to TCP and or TLS that makes addressing issues unrealistic? Linux kernel has had TFO support for years and it didn't take decades for SYN cookies or SACKs to hit all but the long tail. There must be at least a dozen or two TLS extensions by now. How hard can it be from a technical perspective to tweak session tickets or whatever vs throwing everything out and reinventing wheels?

      QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself.

      Not sure retrofitting IP stacks into applications qualifies as a feature. More of the same thing duplicated everywhere usually means a bigger headache for all.

      Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.

      These are political not technical arguments. Heads of state routinely whine about not being "king" yet there are advantages to not so easily having your way.

      I totally understand why Google is doing what their doing. If you own the net stack and the browser and the servers and are a big enough player this is a completely understandable and logical approach to accomplish your goal.

      As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value.

      I'll assume it can cost nothing in terms of CPU, I/O or Time.

      A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful.

      Not everyone has the same problems or constraints. Caution against mapping your experiences onto the rest of the world and drawing conclusions from it.

      I may need to use a specialized security layer.

      I may care about the ability for agents to passively monitor a telemetry stream.

      I may care only about integrity of a message.

      I may be prohibited by law or corporate rules from encrypting data.

      I may have a mission critical system where any use of encryption is an unnecessary potential for failure.

      Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.

      Yes at a minimum any TCP + TLS solution would require minimum 2 separate unavoidable round trips - one for TCP and a second for TLS regardless of construction if state / cookies / tickets / whatever were not available for TCP and or TLS. So what?

    20. Re: What is wrong with SCTP and DCCP? by mrchaotica · · Score: 2

      Do you think that there should be an RFC before the protocol is fully baked?

      Do you know what the acronym "RFC" fucking means?!

      If you have no intention of accepting "Comments" suggesting changes to your protocol, then WTF is the point of submitting a "Request For" them?

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    21. Re:What is wrong with SCTP and DCCP? by Anonymous Coward · · Score: 1

      hey. we reject kings, etc etc etc

      write a spec, get three interoperable implementations developed independently, then
      lets go to town

      100,000 of undigestable c++ doesn't quite look the same

    22. Re: What is wrong with SCTP and DCCP? by ThePhilips · · Score: 1

      [...] TLS on TCP is lots slower when there is any packet loss.

      And how a (almost) stateless protocol like QUIC supposed to handle the packet loss any better?

      The previous write-ups about the Google protocols were all like one based on the premise that packet loss is a very very rare occurrence. That's why they use effectively a stateless transport: because they assume that errors are rare. In other words, they are too very bad at handling it.

      Coming from the old days of IPX vs TCP debates, I remember how the IPX proponents were going abruptly silent in the face of a bad network connection: IPX wasn't able to transfer literally anything, while TCP slowly was churning data, allowing to download OS update and fix the issue. It would be hilarious (and not unexpected) if (or rather when) Google would step into the same cowpie.

      --
      All hope abandon ye who enter here.
    23. Re: What is wrong with SCTP and DCCP? by grmoc · · Score: 1

      RFCs no longer mean request-for-comments, at least in the IETF context.

    24. Re: What is wrong with SCTP and DCCP? by grmoc · · Score: 1

      Dude, the code is open. Then a spec is written, potentially with modifications, if it proves useful.
      You *don't* have to use it.

  2. Well... by koan · · Score: 1

    It sounds a bit like a coding cluster fuck.

    Side note: Anyone using Comcast? I notice that all my Google services are extremely slow at least some of the day, everyday.
    When I turn on VPN there is no issue, I'd to say it's routing... but at this point don't we all know better?

    --
    "If any question why we died, Tell them because our fathers lied."
    1. Re:Well... by drinkypoo · · Score: 2

      The official explanation is that there is insufficient peering 'twixt Comcast (or $OTHER_ISP) and Google, and that's the congested link.

      Of course, other Google services have no such problems at such times, which makes me suspect it's bullshit. But that's still the story.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Well... by koan · · Score: 1

      Ahhh haven't heard that one....

      --
      "If any question why we died, Tell them because our fathers lied."
  3. Oh good! by 93+Escort+Wagon · · Score: 4, Insightful

    I bet QUIC will make those DART-driven VP9 video services really SPDY.

    --
    #DeleteChrome
  4. Second link is empty A tag by GrayNimic · · Score: 1

    The second link in the story ("half of the traffic from Chrome browsers is using QUIC already") is broken - it's an empty <a> tag, with no href. Also means we can't workaround it, since we don't have any hints about the destination.

    1. Re:Second link is empty A tag by GrayNimic · · Score: 2

      Though the first link's article does mention the destination, https://blog.chromium.org/2015...

  5. Proxies share key? by CaptQuark · · Score: 1

    QUIC is designed so that if a client has talked to a given server before, it can can start sending data without any round trips, which makes web pages load faster.

    So, if I have three clients behind a NAT or proxy, do they all share the same TLS key? Does that mean my encryption is compromised in a WiFi environment?

    ~~

    1. Re:Proxies share key? by SuricouRaven · · Score: 2

      No, and no more than usual.

  6. Stupid NAT. by SuricouRaven · · Score: 3, Interesting

    It's impossible to introduce any new transport-layer protocols now, because the vast majority of connected devices are behind at least one layer of NAT, and that means transport protocols can only work if the router support them. We're stuck with TCP and UDP, and no chance of deploying any potentially better alternatives.

    Bring on IPv6! Coming soon since 1998.

    1. Re:Stupid NAT. by amaurea · · Score: 2

      It is coming, finally. In 2010 0.1% of the connections to Google's services were native ipv6, and about the same used 6to4. Now, about 6% of the connections are native ipv6, while 6to4 is almost completely gone. 6% is enough that it's actually starting to matter. The fraction currently seems to be growing by 2.5 percentage points per year, though it might still be accelerating. So perhaps we will finally be free from the curse of NAT in a few more decades.

    2. Re:Stupid NAT. by drinkypoo · · Score: 1

      Do you think they are going to pull up all their existing systems renumber every internal machine, make them all publicly accessible, give each a unique IP from the range allocated, etc.

      Wow, it's almost like you're completely ignorant of how networking actually works, and yet still posted on slashdot anyway!

      UDP works JUST FINE with NAT, if you haven't noticed.

      Yes, as long as the firewall is stateful. Otherwise you need protocol support to receive responses.

      People have this thing about NAT being evil but it's not.

      No, certain protocols are evil, like SIP, and NAT exacerbates that evil. As such, it's not evil, just a massive PITA.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:Stupid NAT. by andrewbaldwin · · Score: 1

      "I can name precisely one ISP in the UK that I know offers IPv6 connectivity"

      Would you mind letting us know who that might be?

      I'm considering moving ISP and want one where I can have a static IP address; looking to the future it seems to me that it's worth having IPv6 support now rather than a second upheaval in a few years time

    4. Re:Stupid NAT. by Lumpy · · Score: 1

      I send custom Transport protocols as well as the "wrong" protocols over port 80 that traverse NAT just fine.

      Routers dont care about the content just the port, the firewall may freak out, but that has nothing to do with routing.

      --
      Do not look at laser with remaining good eye.
    5. Re:Stupid NAT. by ledow · · Score: 1

      Andrews & Arnold.

    6. Re:Stupid NAT. by tgetzoya · · Score: 1

      https://en.wikipedia.org/wiki/... The U stands for UDP.

    7. Re:Stupid NAT. by andrewbaldwin · · Score: 1

      Thanks

      I've heard good things about A & A and they're high on my list of potential new suppliers

  7. Re:Encryption? by Opportunist · · Score: 1

    The main difference I'd see is that it's much harder if not impossible to spoof an IP address in a TCP connection, considering that it takes a completed handshake before any meaningful traffic (read: lots of bits) can take place. I could for example see this making upstream filtering of DDoS attacks more difficult.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  8. shit is it that bad already? by Virtucon · · Score: 1

    From the summary:

    UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP. ... That's why UDP is great for gaming services.

    Stateful vs. Stateless, Connection Oriented vs Connectionless. These are all at the core of TCP/IP and specifically TCP vs. UDP and the reliability contract that each protocol provides. It's not that "one's better than the other at error correction."

    --
    Harrison's Postulate - "For every action there is an equal and opposite criticism"
    1. Re:shit is it that bad already? by Anonymous Coward · · Score: 1

      One actually does error detection and re-transmits.

  9. Given Google's past protocols by heroine · · Score: 1

    Does this mean all web pages are going to partially reload for 5 minutes, toggling between 2 resolutions, then give up with a static filled error message?

  10. Re:Just say no by WaffleMonster · · Score: 1

    And WaffleMonster just wants to bash Google for his/her own benefit (i.e. paid by MS).

    Was in the room for delivery of one-sided Google presentations touting benefits of aggressive congestion schemes and ICW settings during TCPM meetings. I honestly fear ease at which clients and servers can cheat and tinker for competitive advantage with completely user land stacks embedded in applications.

    Wording was probably a little unfair and oversimplified yet I believe in the general theme. I don't work for a large corporation and have little interest in this space other than promotion of an open decentralized Internet.