4 ms·

SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. This is gonna require massive infrastructure changes

by riobard 10y ago

SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. This is gonna require massive infrastructure changes and probably won't fly (like IPv6). QUIC, which runs over UDP, is easier to adopt. However, in reality many ISPs and company networks de-prioritize UDP traffic so the quality of connection is unpredictable. TCP is still the safest bet. We need to figure out a better (and magical!) way somehow...

AndrewDucker 10y ago
IPv6 is over 10% of Google's traffic, and is doubling year-on-year. If SCTP was failing to fly that badly it would make me very happy!
- daenney 10y ago
  But its taken us 20 years to get to this point and even with the IPv4 exhaustion it's still relatively slow to be picked up on by providers in Europe or North America (except for mobile, now). Not to say I wouldn't want SCTP to succeed but IPv6 doesn't exactly spring to mind as a model for the successful adoption of a new internet protocol.
panic 10y ago
SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. Is this true? As far as I can tell SCTP works over plain IP, just like UDP and TCP do.
- riobard 10y ago
  SCTP uses IP protocol number 132. TCP is 6 and UDP is 17. Many middle boxes, especially cheap home routers, are not aware of IP protocols other than TCP/UDP (and maybe GRE/ESP if you're lukcy). Their NAT will not work with SCTP.
  - garaetjjte 10y ago
    But there's IPv6 coming. (so NATs will be gone)
    - alyandon 10y ago
      That really assumes residential ISPs out there decide to fully embrace the idea behind IPv6 instead versus doing something asinine like handing out a single /128 address. Fortunately, mine hands me a /64 so I'm not in that situation. :)
staunch 10y ago
> However, in reality many ISPs and company networks de-prioritize UDP traffic so the quality of connection is unpredictable. What makes you think this? I play a UDP-based FPS game where "ping" times are critically important and it seems like latencies across the board have continued to drop over the years. Latencies are ~2x the speed of light in most case. Not too shabby.
- riobard 10y ago
  Your connection looks pretty good. My home ISP throttles UDP traffic to about 5Mbps while TCP reaches 80+Mbps. Packet loss during peak hours can be as high as 60% for UDP but a manageable single digit percent for TCP. My workplace has anti-BitTorrent mechanism deployed and any meaningful amount of UDP outbound traffic is dropped.
DanielDent 10y ago
[quickly becoming standard comment for me]: IPv6 is in widespread use. IPv6 is not "the future". It's the present. I have services in production where >30% of users access the service over v6. Use is growing. IPv6-only mobile operators are also now a thing. The idea that middle boxes need to be aware of protocols is incredibly destructive to the end-to-end principal - the critical property of IP networks that enables a rapid pace of permissionless innovation. Middleboxes are evil incarnate. Fortunately, academic research as well as operational experience has shown that TCP and UDP provide the primitives required to build any protocol. QUIC, which you mentioned, is an example of this. Google has made the explicit - and probably wise - decision to keep protocol state encrypted. While there would be some nice optimizations possible if routers could be aware of things like 'this session is closed now', the risk of middleboxes making it so that the protocol can't continue to evolve is too great. The solution is to specifically prevent middleboxes from having the knowledge needed meddle in an 'intelligent' way. The last statistics I saw from Google were that 95% of networks don't cause problems for QUIC (i.e. QUIC connections are as fast or faster than HTTP/2). The main issue I'm aware of is not so actually de-prioritization but rather rate limiting (it's often implemented as a quick - and very very dirty - DDoS mitigation technique). Google's stated solution is to fallback to HTTP/2 based on measurements of user experience on a per-AS basis. Networks which try to be "intelligent" rather than just provide adequate bandwidth will tend towards providing a crappy user experience. Solutions which optimize for well behaved adequately provisioned networks and have an acceptable-though-degraded fallback seems like a reasonable way to promote progress. SCTP has an RFC-defined UDP encapsulation which will deal with many evil networks.
- eeeeeeeeeeeee 10y ago
  Until you can run an IPv6 service without dual-stack, it's not in the present in the same way you're talking about. We are still very much in the transition period. Yes, it's positive to see IPv6 growth, but the fact remains that any new service today must provide both IPv4 and IPv6 end-points and that is likely to continue for years.
- nucleardog 10y ago
  > IPv6 is in widespread use. IPv6 is not "the future". It's the present. I have services in production where >30% of users access the service over v6. Use is growing. IPv6-only mobile operators are also now a thing. That's... great, and I'm glad there's progress being made somewhere, but I don't think it's fair to say it's "the present". It's on its way. My ISP has rolled out FttH across a wide area but still only offers IPv6 on business buildouts. Even if they offered IPv6 to general customers, they still have a ton of home gateway devices out there that don't support any IPv6 at all. The other ISPs don't offer it or have any external roadmap either. I don't think this situation is all that unusual or unique - it's just not something that the people paying the bills are clamouring for and it's a long road from where we are to significant penetration. Oh, and EC2 still doesn't support IPv6 on anything but their load balancers. What portion of the market and traffic do you think they make up?

by riobard 10y ago

AndrewDucker 10y ago

IPv6 is over 10% of Google's traffic, and is doubling year-on-year. If SCTP was failing to fly that badly it would make me very happy!

daenney 10y ago
But its taken us 20 years to get to this point and even with the IPv4 exhaustion it's still relatively slow to be picked up on by providers in Europe or North America (except for mobile, now). Not to say I wouldn't want SCTP to succeed but IPv6 doesn't exactly spring to mind as a model for the successful adoption of a new internet protocol.

panic 10y ago

SCTP is problematic because middle boxes need to be made aware of it since it uses a different IP protocol. Is this true? As far as I can tell SCTP works over plain IP, just like UDP and TCP do.

riobard 10y ago
SCTP uses IP protocol number 132. TCP is 6 and UDP is 17. Many middle boxes, especially cheap home routers, are not aware of IP protocols other than TCP/UDP (and maybe GRE/ESP if you're lukcy). Their NAT will not work with SCTP.
- garaetjjte 10y ago
  But there's IPv6 coming. (so NATs will be gone)
  - alyandon 10y ago
    That really assumes residential ISPs out there decide to fully embrace the idea behind IPv6 instead versus doing something asinine like handing out a single /128 address. Fortunately, mine hands me a /64 so I'm not in that situation. :)

staunch 10y ago

> However, in reality many ISPs and company networks de-prioritize UDP traffic so the quality of connection is unpredictable. What makes you think this? I play a UDP-based FPS game where "ping" times are critically important and it seems like latencies across the board have continued to drop over the years. Latencies are ~2x the speed of light in most case. Not too shabby.

riobard 10y ago
Your connection looks pretty good. My home ISP throttles UDP traffic to about 5Mbps while TCP reaches 80+Mbps. Packet loss during peak hours can be as high as 60% for UDP but a manageable single digit percent for TCP. My workplace has anti-BitTorrent mechanism deployed and any meaningful amount of UDP outbound traffic is dropped.

DanielDent 10y ago

[quickly becoming standard comment for me]: IPv6 is in widespread use. IPv6 is not "the future". It's the present. I have services in production where >30% of users access the service over v6. Use is growing. IPv6-only mobile operators are also now a thing. The idea that middle boxes need to be aware of protocols is incredibly destructive to the end-to-end principal - the critical property of IP networks that enables a rapid pace of permissionless innovation. Middleboxes are evil incarnate. Fortunately, academic research as well as operational experience has shown that TCP and UDP provide the primitives required to build any protocol. QUIC, which you mentioned, is an example of this. Google has made the explicit - and probably wise - decision to keep protocol state encrypted. While there would be some nice optimizations possible if routers could be aware of things like 'this session is closed now', the risk of middleboxes making it so that the protocol can't continue to evolve is too great. The solution is to specifically prevent middleboxes from having the knowledge needed meddle in an 'intelligent' way. The last statistics I saw from Google were that 95% of networks don't cause problems for QUIC (i.e. QUIC connections are as fast or faster than HTTP/2). The main issue I'm aware of is not so actually de-prioritization but rather rate limiting (it's often implemented as a quick - and very very dirty - DDoS mitigation technique). Google's stated solution is to fallback to HTTP/2 based on measurements of user experience on a per-AS basis. Networks which try to be "intelligent" rather than just provide adequate bandwidth will tend towards providing a crappy user experience. Solutions which optimize for well behaved adequately provisioned networks and have an acceptable-though-degraded fallback seems like a reasonable way to promote progress. SCTP has an RFC-defined UDP encapsulation which will deal with many evil networks.

eeeeeeeeeeeee 10y ago
Until you can run an IPv6 service without dual-stack, it's not in the present in the same way you're talking about. We are still very much in the transition period. Yes, it's positive to see IPv6 growth, but the fact remains that any new service today must provide both IPv4 and IPv6 end-points and that is likely to continue for years.
nucleardog 10y ago
> IPv6 is in widespread use. IPv6 is not "the future". It's the present. I have services in production where >30% of users access the service over v6. Use is growing. IPv6-only mobile operators are also now a thing. That's... great, and I'm glad there's progress being made somewhere, but I don't think it's fair to say it's "the present". It's on its way. My ISP has rolled out FttH across a wide area but still only offers IPv6 on business buildouts. Even if they offered IPv6 to general customers, they still have a ton of home gateway devices out there that don't support any IPv6 at all. The other ISPs don't offer it or have any external roadmap either. I don't think this situation is all that unusual or unique - it's just not something that the people paying the bills are clamouring for and it's a long road from where we are to significant penetration. Oh, and EC2 still doesn't support IPv6 on anything but their load balancers. What portion of the market and traffic do you think they make up?