I saw that SCTP is going to be used for Data Channels starting in Chrome 31, and officially RTP based channels are going to be deprecated sometimes in February 2014 according to this google group thread:
https://groups.google.com/forum/#!topic/discuss-webrtc/y2A97iCByTU
Does this also mean that webrtc audio and video channels are also going to be transported over SCTP eventually(if not already in the works)?
How does RTP fit in the whole SCTP transport effort? Does that mean SRTP packets will flow over SCTP data channel? Or perhaps just the payload will be sent over SCTP transport protocol.
If I am reading info on SCTP, it combines best of TCP and UDP protocols; but it does not include encryption by default; so in mind the traffic flowing over should still be encrypted.
Any additional info would be helpful. Thanks!
The audio and video will keep going over RTP (actually SRTP which is the secure version or RTP) but the data channel will uses SCTP over DTLS over UDP. Both Firefox and Chrome are implementing this and you can find it described in the IETF draft specifications. For some types of NAT / Firewall traversal, the UDP packets may get tunneled in TURN over TCP.
Glad to provide you pointers to the draft specifications if that helps.
SCTP stands for Stream Control Transmission Protocol.
SCTP as a protocol can be seen as a hybrid of UDP and TCP.
At its core, SCTP holds the following characteristics:
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC
Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not
Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not
Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent
Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested
SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.
Google is experimenting with the QUIC protocol as a future replacement to SCTP
Related
I was researching on QUIC protocol and my professor asked me this question. QUIC is said to be built on UDP and uses TLS packets. TLS itself requires reliable connection that is TCP. So, why QUIC is not said to be built on TCP?
PS: Please correct me if my concepts are wrong and if possible, please explain in deep how QUIC packets work.
QUIC is said to be built on UDP and uses TLS packets.
QUIC (RFC 9000) does not use TLS "packets".
Technically, TLS uses the term "record" to indicate a block of bytes that defines how the protocol is framed. A record specifies the TLS protocol version, the length of the record, etc.
Inside TLS frames there are one or more TLS messages that specify cryptographic information or commands.
The TLS records are transported by TCP.
What QUIC does instead is to reuse some of the TLS messages, but nothing of the TLS record layer.
For example, in TCP the first bytes sent by a client are typically a TLS record that wraps the ClientHello message.
In QUIC, instead, the first bytes are a QUIC Initial packet, that wraps a CRYPTO frame, that wraps the ClientHello message, and all of these bytes must fit into a UDP datagram (they typically do, and the Initial packet even carries a PADDING frame to make the initial bytes at least 1200).
Refer to RFC 9001 for more details about how TLS is used in QUIC.
More broadly about QUIC, it is based on UDP but borrows many TCP features (retransmissions, flow control, etc.) that basically make it an alternative to TCP in the sense that it is a reliable network protocol, with additional security (encryption) features built-in, borrowed by TLS.
TCP is clear-text and relies on TLS layered on top to provide encryption.
QUIC is a mix of TCP features and TLS features (there is no clear-text QUIC), without layering.
When you say "Why QUIC is not said to be built on TCP?", I say "QUIC is not built on TCP, it is built on UDP. However, QUIC borrows TCP features that make QUIC provide similar functionalities as TCP, in particular reliability and flow control, that are not provided by UDP".
For example, in Jetty we have implemented HTTP/1.1 and HTTP/2 (that are TCP-based protocols) on top of QUIC, using a single, persistent, QUIC stream.
This shows that QUIC can be indeed a replacement for TCP, as it can carry protocols that were designed for TCP.
QUIC includes TLS in it to allow it to be used over UDP in the same way as TCP works.
Why bother reinventing TCP and not just use TCP? Well TCP is kind of “stuck” as it’s slow to roll out new changes that fundamentally change how TCP works. Enhancing it to allow new features like multiplex streams will take a loooong time to roll out everywhere TCP is supported.
QUIC is built over simple UDP packets and everything else is handled at either end by QUIC and all the routers and networks in the middle don’t need to know about these new QUIC features.
The RFCs are all written by committee, and the structure and language is often confusing, so it is easy to mix things up.
A full TLS implementation requires a reliable transport, which as of today is provided by TCP and SCTP (RFC3436).
QUIC (RFC9001) doesn't actually require a full TLS implementation though, and instead simply re-uses parts of the TLSv1.3 standard:
4.1. Interface to TLS
As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions:
* Sending and receiving handshake messages
* Processing stored transport and application state from a resumed
session and determining if it is valid to generate or accept 0-RTT
data
* Rekeying (both transmit and receive)
* Updating handshake state
So, given the above, the actual process that QUIC takes to encrypting the packet data isn't TLS at all, but is instead provided by QUIC.
Can someone point me to some documentation on how to implement a Bittorrent UDP application?
I am working on a Bittorrent application and I can successfully download using TCP but I want to implement UDP and I can't find any information on it. I am retrieving peers with UDP trackers but that approach appears different than downloading files.
If I sniff a UDP Handshake I see the following in Wireshark:
172.16.49.213 5.31.44.30 UDP 62 35507 → 18318 Len=20
5.31.44.30 172.16.49.213 UDP 62 18318 → 35507 Len=20
This is done before the handshake. Also, it looks like there are 20 bytes prepended to the Handshake (different than the 20 bytes above).
So I need some information to help me with what all this means.
The BitTorrent Peer Wire Protocol over UDP, called uTP is specified in:
BEP29 - uTorrent transport protocol
BitTorrentInc has also published uTP as a IETF RFC were they call it LEDBAT:
RFC 6817 - Low Extra Delay Background Transport (LEDBAT)
However, I wouldn't recommend anyone to do their own implementation, (except as a learning experience), as it involves a lot of time critical, low level network IO and is very tricky to get right.
Instead I recommend to use the library: https://github.com/bittorrent/libutp
Almost all clients implementing uTP uses this library. AFAIK, the only exception is libtorrent/rasterbar (used by qBittorrent and Deluge) and it don't work as good as libutp does.
I was reading and trying to find out about WebRTC's RTCDataChannel. As I understand Websockets are on top of TCP and have higher latency than SCTP that underlies WebRTC, when for example sending binary data between server and browser, that also could be 2 peers in WebRTC. When RTCDataChannel is set to unreliable mode (possible package loss but faster), its underlying SCTP becomes analogous to User Datagram Protocol (UDP) and when set to reliable it becomes TCP-like.
Is RTCDataChannel, when configured to be reliable (“TCP-like”), still faster then Websockets (TCP) and if so, how much faster?
I saw that SCTP is going to be used for Data Channels starting in Chrome 31, and officially RTP based channels are going to be deprecated sometimes in February 2014 according to this google group thread:
https://groups.google.com/forum/#!topic/discuss-webrtc/y2A97iCByTU
Does this also mean that webrtc audio and video channels are also going to be transported over SCTP eventually(if not already in the works)?
How does RTP fit in the whole SCTP transport effort? Does that mean SRTP packets will flow over SCTP data channel? Or perhaps just the payload will be sent over SCTP transport protocol.
If I am reading info on SCTP, it combines best of TCP and UDP protocols; but it does not include encryption by default; so in mind the traffic flowing over should still be encrypted.
Any additional info would be helpful. Thanks!
The audio and video will keep going over RTP (actually SRTP which is the secure version or RTP) but the data channel will uses SCTP over DTLS over UDP. Both Firefox and Chrome are implementing this and you can find it described in the IETF draft specifications. For some types of NAT / Firewall traversal, the UDP packets may get tunneled in TURN over TCP.
Glad to provide you pointers to the draft specifications if that helps.
SCTP stands for Stream Control Transmission Protocol.
SCTP as a protocol can be seen as a hybrid of UDP and TCP.
At its core, SCTP holds the following characteristics:
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC
Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not
Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not
Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent
Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested
SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.
Google is experimenting with the QUIC protocol as a future replacement to SCTP
WebRTC DataChannels use SCTP. Looking at the graph of bits received from chrome://webrtc-internals, there is a regular sending of a small amount of data. Is this the SCTP heartbeat?
From what I understand, this is the ICE heartbeat.
I am just elaborating Sam's answer.
WebRTC DataChannel uses Stream Control Transport Protocol (SCTP) for sending
and receiving arbitrary data. Since, WebRTC requires that all WebRTC traffic be
encrypted, DTLS is used. However, most routers and NAT devices don't handle this
protocol well. Hence, SCTP is tunneled over DTLS and UDP. Now, even when two
peers are exchanging arbitrary data, it is happening over UDP. Hence, I too
believe that it is not a SCTP heartbeat.
As you might know, RTCPeerConnection uses ICE for resolving connectivity issues between
peers. ICE uses STUN keep-alives to check the connectivity status between
the peers. Currently, I believe chrome sends out STUN Binding Request every 450 ms to perform connectivity checks, but there is an ongoing discussion on extending that time interval.