[zAy0LfpBZLC8mAC]

For one, it's not, because PMTUD and stuff.

More importantly: You are missing the point. Great, you have encapsulated your protocol in UDP. Now, what do you notice? Your ISP is throttling your protocol because for some braindead reason their traffic management has categorized it as some sort of unimportant protocol, probably P2P or something. Or they just throttle UDP in general, because who uses UDP besides DNS and VoIP? So, high bandwidth UDP usage is obviously a DoS, and we don't want that! If you are unlucky, maybe they even shut off your server because it is obviously part of a botnet?

OK, so enough people complain to their ISPs that SCTP over UDP doesn't work. What happens? Exactly, ISPs start putting in rules that "recognize SCTP over UDP". So next time you want to try out a new protocol or extend SCTP somehow, you run into the exact same problem.

The difficult part isn't stuffing bytes into UDP packets, the difficult part is making sure it actually works reliably and fast over the public internet.

[tathougies]

Everything you wrote about SCTP over UDP applies equally to QUIC

[zAy0LfpBZLC8mAC]

No, it doesn't.

1. While getting telcos to fix their network so that QUIC works optimally might also need some work, it should be easier than for unencapsulated SCTP for the simple reason that (a) there is a relevant proportion of the network that already does work fine with it, so it is easier to blame the bad providers when things don't work so well with some provider that throttles UDP, say, and (b) in the case of simple UDP throttling, QUIC is in competition with VoIP and DNS, which could lead to degradation of those other services, which should increase the pressure to fix things. And in any case, you at least don't need to touch all CPE, only middle boxes within the infrastructure.

2. Probably more improtantly, SCTP is a plain text protocol, so getting it to work over telcos' networks does not help you at all the next time around when you want to evolve protocols. Once the work is done for QUIC, you won't have to do it ever again, because anything new that you could come up with is easily made indistinguishable from QUIC as far as the telco is concerned.

[tathougies]

> SCTP is a plain text protocol,

There's an old phrase: better to keep your mouth shut and be assumed a fool, than to open it and remove all doubt.

SCTP is not a plain text protocol. I'm not sure how you managed to convince yourself of this one.

Here is the bit-by-bit format of the SCTP header, in case you were ever confused again:

https://tools.ietf.org/html/rfc4960#section-3.1

In the above post, I was talking about SCTP over UDP, which is an IETF standard already. You have moved the goal posts by talking about unencapsulated SCTP. We all agree that this is a tough problem. However, QUIC is also encapsulated over UDP, and when encapsulated, has the same advantages / disadvantages as SCTP over UDP.

SCTP over UDP over DTLS already constitutes a good portion of web traffic, since WebRTC (and hence technologies like hangouts, facebook video messaging, etc) is based on it.

[zAy0LfpBZLC8mAC]

> SCTP is not a plain text protocol. I'm not sure how you managed to convince yourself of this one.

> Here is the bit-by-bit format of the SCTP header, in case you were ever confused again:

> https://tools.ietf.org/html/rfc4960#section-3.1

I can not find there a single hint that anything is encrypted, and I would have been very surprised if I had. The security considerations do even explicitly acknowledge that it's up to the application to encrypt the payload if it wants to.

> In the above post, I was talking about SCTP over UDP, which is an IETF standard already. You have moved the goal posts by talking about unencapsulated SCTP.

No, I simply covered that case as well because SCTP on IP was mentioned as a supposedly viable alternative in this discussion as well, which supposedly would be preferable over QUIC because of lower overhead (which is true if it works, of course).

> However, QUIC is also encapsulated over UDP, and when encapsulated, has the same advantages / disadvantages as SCTP over UDP.

No, it then has the advantage of being nearly completely encrypted, so we don't get any protocol ossification.

> SCTP over UDP over DTLS already constitutes a good portion of web traffic, since WebRTC (and hence technologies like hangouts, facebook video messaging, etc) is based on it.

Well, yeah, but then what's the advantage over QUIC? It's also a complete flow control and encryption stack in user space if you want to run it over DTLS! I mean, I don't mind SCTP, but it's not like the kernel implementation is of any help when you want to run it over DTLS ...

[_fq4v]

> I can not find there a single hint that anything is encrypted, and I would have been very surprised if I had. The security considerations do even explicitly acknowledge that it's up to the application to encrypt the payload if it wants to.

Plain text is typically used as the opposite of 'binary'. You are intending to say 'unencrypted' or 'clear text', not 'plain text'. SCTP is not encrypted by default. It is a transport protocol and it is intended that

> Well, yeah, but then what's the advantage over QUIC? It's also a complete flow control and encryption stack in user space if you want to run it over DTLS! I mean, I don't mind SCTP, but it's not like the kernel implementation is of any help when you want to run it over DTLS ...

the advantage is that DTLS over SCTP is an internet standard that was created organically by a variety of motivated individuals and organizations. DTLS over SCTP does not require kernel encryption, and is implementable in userspace. This is similar to how TLS is implemented in userspace but uses the kernel TCP drivers. SCTP has been a standard for almost two decades and DTLS over SCTP for a similarly long time. There is no reason to replace something that works, with something that is exactly the same, except for the fact it's invented by Google.

You claim QUIC is encrypted. It is not. QUIC is a transport protocol and transport protocols need their headers to be inspectable to provide good routing, etc. The payloads are encrypted, like any other transport protocol.

The point is that there is no technical advantage to QUIC over DTLS over SCTP over UDP. Thus, we should reject the new standard in favor of the existing one.

This is similar to how, if someone made a POSIX-like specification that fulfilled all the same requirements as POSIX, we shouldn't simply adopt because it's newer. If the new technology offers no advantage over the old, then the new technology should be rejected as offering nothing new.

[zAy0LfpBZLC8mAC]

> Plain text is typically used as the opposite of 'binary'. You are intending to say 'unencrypted' or 'clear text', not 'plain text'. SCTP is not encrypted by default. It is a transport protocol and it is intended that

https://en.wikipedia.org/wiki/Plaintext

Also, context. None of what I wrote makes any sense under the assumption that I was talking about a 'character string protocol'.

> the advantage is that DTLS over SCTP is an internet standard that was created organically by a variety of motivated individuals and organizations. DTLS over SCTP does not require kernel encryption, and is implementable in userspace. This is similar to how TLS is implemented in userspace but uses the kernel TCP drivers.

Which is true, but obviously does not apply to SCTP over DTLS, which is what you were talking about in your previous post.

> There is no reason to replace something that works, with something that is exactly the same, except for the fact it's invented by Google.

Well, true. Which is why it is relevant that QUIC is not exactly the same, as I have explained a dozen times now.

> You claim QUIC is encrypted. It is not. QUIC is a transport protocol and transport protocols need their headers to be inspectable to provide good routing, etc. The payloads are encrypted, like any other transport protocol.

Routing happens at the IP layer, so, no, a transport protocol does not need to be inspectable. And in fact it is an explicit design goal of QUIC to minimize what is inspectable. Which is why it is essentially uninspectable.

All that is inspectable is a connection ID and a packet sequence number. The sequence number doesn't really tell you anything as it is not even a sequence number of payload segments, but only of transport packets (so retransmits get new sequence numbers). The connection ID tells you which packets form a connection ... but then there is essentially one connection between two endpoints, so nothing to see there either that isn't obvious from the network layer anyway.

But none of the flow control machinery is inspectable by the network, and even the unencrypted header fields are still authenticated so as to prevent any meddling by middle boxes. Also, you know, you can read all of this in the specification, maybe that'd be better than removing more doubt?

https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#sec...