Subject: QUIC for robotics and other time-sensitive applications

From: John Wason <[email-masked]>
Date: Tue, 30 Apr 2019 15:14:41 -0400

Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my 
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a 
communication framework for robotics and automation systems 
(https://github.com/robotraconteur/robotraconteur). Robotics 
applications require different data types and QoS when compared to 
business or web applications. Robotics applications need real-time 
communication of isochronous data, for instance constant updates on the 
position of the joints of the robot, alongside generic 
non-time-sensitive data. Currently most robotics applications are using 
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form 
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add 
more confusion to the situation, there is the recent introduction of 
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP 
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur 
and OPC/UA are compatible with existing web and cloud infrastructure. 
(Some limited support for ROS/ROS2 has become available on AWS, but the 
design of ROS does not play very well outside of local networks.*) Robot 
Raconteur implements web browser and web server support by allowing the 
websocket protocol to be used. Clients can use a URL that specifies that 
the connection is a websocket, and incoming TCP connections can detect 
if the connection is the Robot Raconteur protocol or an incoming 
websocket connection. Robot Raconteur running inside an ASP.NET web 
server has been demonstrated, and there is no technical reason that 
other server technologies cannot accept Robot Raconteur connections 
through websockets. (OPC/UA uses SOAP for its web based transport, but 
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications 
is the use of TCP for data transport. TCP suffers from "head-of-line" 
blocking, which means that if stale data encounters an error it can stop 
fresh data from reaching the other peer. There is also the problem of 
large messages blocking the transmission of smaller, more time sensitive 
messages on the connection. QUIC appears to solve most of these 
problems, and the webrtc-quic support under development provides a lot 
of new and interesting opportunities for integrating robotics 
applications with web technology. By adopting QUIC, the resulting 
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and 
prioritize) messages and drop messages if the data contained becomes 
stale. The multiplexing issue is solved using the "streams as messages" 
concept in QUIC, with built in priority handling. This design looks very 
promising, and considerably simpler to use compared to SCTP streams. The 
current issue that is somewhat questionable is the implementation of 
partial reliability. The discussion right now is focused on DATAGRAM 
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access 
to the socket so protocols such as RTP can tunnel through QUIC. This 
requirement is quite a bit different than what is required for an 
application like Robot Raconteur. Robot Raconteur is based on message 
passing, where either the entire message is received or the entire 
message is cancelled because the data contained is stale. The message 
may be considerably larger than MTU, and the QoS may be "partial," 
meaning that a set number of attempts may be made to resend, and/or 
there is an expiration time on the message. This capability is discussed 
in draft-lubashev-quic-partial-reliability-03, and is similar to how 
SCTP handles partial reliability. If only a raw DATAGRAM capability is 
provided, then partial reliability will need to be built on top of QUIC, 
defeating the purpose of using QUIC for this application. Other 
applications such as online gaming have very similar performance 
requirements, so I think that the partial reliability capability will be 
important to many future users.

The complexity and required effort to add the partial reliability 
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM 
Institute and New York State to begin commercializing the technology. 
This project will be done in partnership with Wason Technology, LLC, 
Rensselaer Polytechnic Institute, Southwest Research Institute, and 
United Technologies Research Center. The project starts soon, and 
considerable development effort will be invested in the Robot Raconteur 
technology starting early summer. Integrating QUIC is one of the tasks 
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or 
the requirements for QUIC in robotics applications.

     -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with 
the wider world, but the technologies are not built on or compatible 
with web standards so an in depth discussion is not relevant for the 
current topic. ROS does have a UDP transport, but it is not commonly used.)

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 30 Apr 2019 14:37:48 -0700

Hi John,

Thanks for the message.  If you have not already reviewed the work of
DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it
might be useful to do so, as there are a number of elements of your use
case which appeared to be shared with their work.  In particular, it might
be useful to consider whether the integration of their proposed IP data
plane (
https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1)
with QUIC would be valuable in achieving your timing goals.

best regard,

Ted Hardie

---

From: John Wason <[email-masked]>
Date: Tue, 30 Apr 2019 17:51:37 -0400

Thanks Ted, this looks very interesting. Based on these documents the 
DETNET sits below the level of QUIC that we are currently discussing and 
would mainly affect the IP header format of the resulting UDP packets. 
The QUIC protocol will still require some form of partial reliability to 
function on a DETNET network.

     -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:
> DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the 
> IETF, it might be useful to do so, as there are a number of elements 
> of your use case which appeared to be shared with their work.  In 
> particular, it might be useful to consider whether the integration of 
> their proposed IP data plane 
> (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) 
> On Tue, Apr 30, 2019 at 12:15 PM John Wason <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Greetings QUIC WG,
>
>     websocket connection. Robot Raconteur running inside an ASP.NET
>     <http://ASP.NET> web
>     [email-masked] <mailto:[email-masked]>
>
-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
[email-masked]