Re: QUIC for robotics and other time-sensitive applications

[John Wason <[e-mail]>]

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:
> 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
>
> On Tue, Apr 30, 2019 at 12:15 PM John Wason <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>     <http://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
>     [phone]
>     [e-mail] <mailto:[e-mail]>
>
-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
[phone]
[e-mail]