3 ms·

Shouldn't this eventually be put in OSI layer 4 (on top of IP instead of on top of UDP) ?

exDM69 10y ago
It would me much more difficult and laborious to implement with no obvious advantages. UDP is already well specified and implemented, it's lightweight and goes through existing firewalls. The overhead of UDP here is pretty much negligible.
- quickben 10y ago
  The advantage is obvious for Google and the rest of us that run hobby search engines. For example: https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 Section 4.3 "A QUIC receiver advertises the absolute byte offset within each stream upto which the receiver is willing to receive data." This is saving the crawler bandwidth by a ton. Limit stuff to 64k and skip all non text data upfront in a very clear cut fashion. 6.2.1.2 prevents hosts spamming you with data after your decided to stop receiving from them. 6.3.2 makes this system fire and forget on a 10m limit and then decide what to do with the host that did or didn't respond with data from the request. 10. Properly download everything from the website (actual priority stuff, central to she protocol, aren't even written, it's a to-do :). All in all, great protocol to help whoever is running search engines. For the rest, won't be the default (they seem to be aware of this in this in 11.5) So trying to guess the future: push quic to Apache/nginx (because 11.5 bypass lots of deployment stuff too), hit websites once and determine who had latest code, cash in on bandwidth. Not bad for a company start. Do we need another protocol? Probably not. Will this see light of day? Probably yes since Google's money are pushing it.
drdaeman 10y ago
The problem is, we've basically lost L4. Too many networks (firewalls, and especially NATs) just don't pass anything but protocols 6 (TCP) and 17 (UDP). Even ICMP is not always reliably available (leading to all sort of weird PMTU issues[1]), or heavily filtered. I think that's why many good protocols (e.g. SCTP) are rare sights and frequently aren't even considered as an option. [1] Yes, some idiots just block ICMP completely because they heard it's "secure" and make DHCP or PPP cap MTU at 1200 with "uh, it works just fine" attitude.
- panic 10y ago
  It's too late for IPv4, but maybe a strong push could get a protocol like SCTP supported on IPv6 networks?
  - wtbob 10y ago
    IIRC IPv6 requires ICMPv6 to work. I'd be in favour of SCTP support as well; dunno how it compares to QUIC for mobile devices though.
  - drdaeman 10y ago
    Given that IPv6 doesn't normally use NAT (and for IPv4, it's NAT, not firewalls, is the primary source of problems why non-TCP/UDP protocols don't work in practice) it's a possibility that it would be okay. IPv6 adoption is a problem, though. I think despite all IANA efforts to push v6, we'll be stuck with IPv4 for long years.
wtbob 10y ago
I think that this is basically what SCTP is/was (maybe with a few improvements: I don't recall how SCTP handled client mobility). The problem, as drdaeman indicates, is that too many networks consider themselves TCP (really, TCP/{80,443}) networks, not actual networks providing IP the way they are supposed to.
yes_or_gnome 10y ago
It's hard, for me, to imagine what they would do differently than UDP (because it's minimal, just two port numbers). Having not yet read the spec for the QUIC protocol, there must be some amount header that would immediately follow the eight UDP bytes. So, assuming that QUIC takes off and gains broad support, then all that would have to be done is give it a new IP protocol number and redefine what is the transport layer and what is session/application layer.

It would me much more difficult and laborious to implement with no obvious advantages. UDP is already well specified and implemented, it's lightweight and goes through existing firewalls. The overhead of UDP here is pretty much negligible.

quickben 10y ago
The advantage is obvious for Google and the rest of us that run hobby search engines. For example: https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00 Section 4.3 "A QUIC receiver advertises the absolute byte offset within each stream upto which the receiver is willing to receive data." This is saving the crawler bandwidth by a ton. Limit stuff to 64k and skip all non text data upfront in a very clear cut fashion. 6.2.1.2 prevents hosts spamming you with data after your decided to stop receiving from them. 6.3.2 makes this system fire and forget on a 10m limit and then decide what to do with the host that did or didn't respond with data from the request. 10. Properly download everything from the website (actual priority stuff, central to she protocol, aren't even written, it's a to-do :). All in all, great protocol to help whoever is running search engines. For the rest, won't be the default (they seem to be aware of this in this in 11.5) So trying to guess the future: push quic to Apache/nginx (because 11.5 bypass lots of deployment stuff too), hit websites once and determine who had latest code, cash in on bandwidth. Not bad for a company start. Do we need another protocol? Probably not. Will this see light of day? Probably yes since Google's money are pushing it.

drdaeman 10y ago

The problem is, we've basically lost L4. Too many networks (firewalls, and especially NATs) just don't pass anything but protocols 6 (TCP) and 17 (UDP). Even ICMP is not always reliably available (leading to all sort of weird PMTU issues[1]), or heavily filtered. I think that's why many good protocols (e.g. SCTP) are rare sights and frequently aren't even considered as an option. [1] Yes, some idiots just block ICMP completely because they heard it's "secure" and make DHCP or PPP cap MTU at 1200 with "uh, it works just fine" attitude.

panic 10y ago
It's too late for IPv4, but maybe a strong push could get a protocol like SCTP supported on IPv6 networks?
- wtbob 10y ago
  IIRC IPv6 requires ICMPv6 to work. I'd be in favour of SCTP support as well; dunno how it compares to QUIC for mobile devices though.
- drdaeman 10y ago
  Given that IPv6 doesn't normally use NAT (and for IPv4, it's NAT, not firewalls, is the primary source of problems why non-TCP/UDP protocols don't work in practice) it's a possibility that it would be okay. IPv6 adoption is a problem, though. I think despite all IANA efforts to push v6, we'll be stuck with IPv4 for long years.

wtbob 10y ago

I think that this is basically what SCTP is/was (maybe with a few improvements: I don't recall how SCTP handled client mobility). The problem, as drdaeman indicates, is that too many networks consider themselves TCP (really, TCP/{80,443}) networks, not actual networks providing IP the way they are supposed to.

yes_or_gnome 10y ago

It's hard, for me, to imagine what they would do differently than UDP (because it's minimal, just two port numbers). Having not yet read the spec for the QUIC protocol, there must be some amount header that would immediately follow the eight UDP bytes. So, assuming that QUIC takes off and gains broad support, then all that would have to be done is give it a new IP protocol number and redefine what is the transport layer and what is session/application layer.