[meta] Open Screen Network Protocol

[markafoltz]

This will begin as everything omitted from the Open Screen Application Protocol (#341) but may evolve over time into one or more specifications.

The motivations for doing so are listed in #341.

The initial draft of the network protocol will include the SPAKE2 authentication ceremony, although it is open for discussion whether that belongs with the application protocol, the network protocol, or should be spun out into a separate specification.

The future prospects for taking up this work in one or more IETF groups will also influence the outcome.

This meta issue tracks work items to draft the network layer protocol. Additional tasks will be posted below as needed.

• [x] Draft spec with network protocol
• [ ] #346

[markafoltz]

Note, the spec name was chosen as a placeholder, and it's likely to be renamed in the future.

[backkem]

I wanted to explore what the network protocol could look like when making an effort to maximally reuse the existing protocols in the WebRTC stack. This is just an exploration at this point. However, it could be relevant since the adoption of QUIC in the real-time space is taking time.

First off, in our LAN setting SDP 'signaling' poses challenges as it requires a side-channel, usually via a cloud service, for which there isn't an obvious alternative in the LAN setting. In addition, the ICE protocol's purpose is mostly for NAT translation. It adds little value in the LAN setting (although it also doesn't hurt). These two protocols are basically what WebRTC uses to open a communication channel between peers. In the OSNP case that would be coveted by LAN service discovery (DNS-SD) + potentially part of the agent-info exchange.

Next, the OSNP needs a communication channel to run the mutual authentication ceremony between the peers. The current specification uses QUIC for reliable delivery of the messages involved. In the excising WebRTC stack SCTP provides reliable delivery. However, for the purposes of the authentication ceremony I would instead opt to run it over DTLS (over UDP, potentially skipping ICE) directly. To ensure messages are delivered I would augment DTLS's Timeout and Retransmission scheme.

Once the connection is authenticated, SCTP can be used as a reliable transport to cary the OpenScreen Application Protocol. Optionally, SRTP can be used for media transport.

[markafoltz]

My understanding is that you plan on dividing the messages in the application protocol between two different transports, one reliable and in-order (SCTP) and the other not (RTP).

One thing to evaluate is whether the application protocol is robust to messages arriving out of order. Also the application protocol does not have any provision for message retransmissions as that is assumed to be handled by the transport layer.

[backkem]

Yea, but with the remark that RTP is made specifically to transport real-time media. In other words, I'd consider handing over the media transport responsibility to an existing purpose-built protocol.

All other Application protocol messages would be transported over reliable SCTP. The QUIC equivalent would be QUIC itself for control messages and RoQ (RTP over QUIC) for (real-time) media.

[backkem]

As en experiment, I abstracted the protocols from their transport (ref) and implemented a DTLS/SCTP variant (ref). Here are some of my takeaways:

Regarding protocol interaction:

• When considering the Network and Application protocol as separate protocols, (while possible) it seems somewhat awkward to wind down the machinery for handling the Network protocol and spin up the handling for the Application protocol on the same "transport" (Unless you inherently intertwine both implementations).
• Therefore, it may be worth considering running them on a separate follow-up connection and just Dialing a new connection for the application protocol, E.g. with a different ALPN.
• Aside from the protocol implementation, there is another reason we may want to consider this: I expect it to be more user friendly to run the Network protocol between the controlling User Agent and a 2nd device, while the Application protocol is likely scoped between one Origin on that controlling User Agent and the 2nd device.

Regarding the (for now purely academic) DTLS/SCTP variant:

• It certainly seems feasible. In addition to what I mentioned above you need to packetize the Application protocol since SCTP is a message based protocol.
• There will be some wiring to figure out especially around how to nudge/avoid ICE and the multiplexing of DTLS/SRTP (rfc5764 & rfc7983) ICE Lite may be a good way to 'skip' ICE.