Appendix A.  Use Cases Explicitly Out of Scope for DetNet

   This appendix contains text regarding use cases that have been
   determined to be outside the scope of the present DetNet work.

A.1.  DetNet Scope Limitations

   The scope of DetNet is deliberately limited to specific use cases
   that are consistent with the WG charter, subject to the
   interpretation of the WG.  At the time that the DetNet use cases were
   solicited and provided by the authors, the scope of DetNet was not
   clearly defined.  As the scope has been clarified, certain use cases
   have been determined to be outside the scope of the present DetNet
   work.  Text regarding these use cases was moved to this appendix to
   clarify that they will not be supported by the DetNet work.

   The text was moved to this appendix based on the following
   "exclusion" principles.  Please note that as an alternative to moving
   all such text to this appendix some text has been modified in situ to
   reflect these same principles.

   The following principles have been established to clarify the scope
   of the present DetNet work.

   o  The scope of networks addressed by DetNet is limited to networks
      that can be centrally controlled, i.e., an "enterprise" (aka
      "corporate") network.  This explicitly excludes "the open
      Internet".

   o  Maintaining time synchronization across a DetNet network is
      crucial to its operation; however, DetNet assumes that time is to
      be maintained using other means.  One example would be PTP
      [IEEE-1588].  A use case may state the accuracy and reliability
      that it expects from the DetNet network as part of a whole system;
      however, it is understood that such timing properties are not
      guaranteed by DetNet itself.  At the time of this writing, two
      open questions remain: (1) whether DetNet protocols will include a
      way for an application to communicate expectations regarding such
      timing properties to the network and (2) if so, whether those
      properties would likely have a material effect on network
      performance as a result.

A.2.  Internet-Based Applications

   There are many applications that communicate over the open Internet
   that could benefit from guaranteed delivery and bounded latency.
   However, as noted above, all such applications, when run over the
   open Internet, are out of scope for DetNet.  These same applications

   may be in scope when run in constrained environments, i.e., within a
   centrally controlled DetNet network.  The following are some examples
   of such applications.

A.2.1.  Use Case Description

A.2.1.1.  Media Content Delivery

   Media content delivery continues to be an important use of the
   Internet, yet users often experience poor-quality audio and video due
   to the delay and jitter inherent in today's Internet.

A.2.1.2.  Online Gaming

   Online gaming is a significant part of the gaming market; however,
   latency can degrade the end user's experience.  For example, "First
   Person Shooter" (FPS) games are highly delay sensitive.

A.2.1.3.  Virtual Reality

   VR has many commercial applications, including real estate
   presentations, remote medical procedures, and so on.  Low latency is
   critical to interacting with the virtual world, because perceptual
   delays can cause motion sickness.

A.2.2.  Internet-Based Applications Today

   Internet service today is by definition "best effort", with no
   guarantees regarding delivery or bandwidth.

A.2.3.  Internet-Based Applications in the Future

   One should be able to play Internet videos without glitches and play
   Internet games without lag.

   For online gaming, the desired maximum allowance for round-trip delay
   is typically 100 ms.  However, it may be less for specific types of
   games; for example, for FPS games, the maximum delay should be 50 ms.
   Transport delay is the dominant part, with a budget of 5-20 ms.

   For VR, a maximum delay of 1-10 ms is needed; if doing remote VR, the
   total network delay budget is 1-5 ms.

   Flow identification can be used for gaming and VR, i.e., it can
   recognize a critical flow and provide appropriate latency bounds.

A.2.4.  Internet-Based Applications Requests to the IETF

   o  Unified control and management protocols that handle time-critical
      data flows

   o  An application-aware flow-filtering mechanism that recognizes
      time-critical flows without doing 5-tuple matching

   o  A unified control plane that provides low-latency service on
      Layer 3 without changing the data plane

   o  An OAM system and protocols that can help provide service
      provisioning that is sensitive to end-to-end delays

A.3.  Pro Audio and Video - Digital Rights Management (DRM)

   The following text was moved to this appendix because this
   information is considered a link-layer topic for which DetNet is not
   directly responsible.

   Digital Rights Management (DRM) is very important to the audio and
   video industries.  Whenever protected content is introduced into a
   network, there are DRM concerns that must be taken into account (see
   [Content_Protection]).  Many aspects of DRM are outside the scope of
   network technology; however, there are cases when a secure link
   supporting authentication and encryption is required by content
   owners to carry their audio or video content when it is outside their
   own secure environment (for example, see [DCI]).

   As an example, two such techniques are Digital Transmission Content
   Protection (DTCP) and High-bandwidth Digital Content Protection
   (HDCP).  HDCP content is not approved for retransmission within any
   other type of DRM, while DTCP content may be retransmitted under
   HDCP.  Therefore, if the source of a stream is outside of the network
   and it uses HDCP, it is only allowed to be placed on the network with
   that same type of protection (i.e., HDCP).

A.4.  Pro Audio and Video - Link Aggregation

   Note: The term "link aggregation" is used here as defined by the text
   in the following paragraph, i.e., not following a more common
   network-industry definition.

   For transmitting streams that require more bandwidth than a single
   link in the target network can support, link aggregation is a
   technique for combining (aggregating) the bandwidth available on
   multiple physical links to create a single logical link that provides

   the required bandwidth.  However, if aggregation is to be used, the
   network controller (or equivalent) must be able to determine the
   maximum latency of any path through the aggregate link.

A.5.  Pro Audio and Video - Deterministic Time to Establish Streaming

   The DetNet WG decided that guidelines for establishing a
   deterministic time to establish stream startup are not within the
   scope of DetNet.  If the bounded timing for establishing or
   re-establishing streams is required in a given use case, it is up to
   the application/system to achieve it.

Acknowledgments

   Pro audio (Section 2)

      As also acknowledged in [DetNet-Audio-Reqs], the editor would like
      to acknowledge the help of the following individuals and the
      companies they represent.

         Jeff Koftinoff, Meyer Sound
         Jouni Korhonen, Associate Technical Director, Broadcom
         Pascal Thubert, CTAO, Cisco
         Kieran Tyrrell, Sienda New Media Technologies GmbH

   Utility telecom (Section 3)

      Information regarding utility telecom was derived from
      [DetNet-Util-Reqs].  As in that document, the following
      individuals are acknowledged here.

         Faramarz Maghsoodlou, Ph.D., IoT Connected Industries
            and Energy Practice, Cisco
         Pascal Thubert, CTAO, Cisco

      The wind power generation use case has been extracted from the
      study of wind parks conducted within the 5GPPP VirtuWind Project.
      The project is funded by the European Union's Horizon 2020
      research and innovation programme under grant agreement No. 671648
      (VirtuWind).

   Building automation systems (Section 4)

      Please see [BAS-DetNet].

   Wireless for industrial applications (Section 5)

      See [DetNet-6TiSCH].

      [DetNet-6TiSCH] derives from the 6TiSCH architecture, which is the
      result of multiple interactions -- in particular, during the
      6TiSCH (bi)weekly interim call, relayed through the 6TiSCH mailing
      list at the IETF [MailingList-6TiSCH].

      As also acknowledged in [DetNet-6TiSCH], the editor wishes to
      thank Kris Pister, Thomas Watteyne, Xavier Vilajosana, Qin Wang,
      Tom Phinney, Robert Assimiti, Michael Richardson, Zhuo Chen,
      Malisa Vucinic, Alfredo Grieco, Martin Turon, Dominique Barthel,
      Elvis Vogli, Guillaume Gaillard, Herman Storey, Maria Rita
      Palattella, Nicola Accettura, Patrick Wetterwald, Pouria Zand,
      Raghuram Sudhaakar, and Shitanshu Shah for their participation and
      various contributions.

   Cellular radio (Section 6)

      See [DetNet-RAN].

   Internet applications and CoMP (Section 6)

      As also acknowledged in [DetNet-Mobile], authored by Yiyong Zha,
      the editor would like to thank the following people for their
      reviews, suggestions, comments, and proposed text: Jing Huang,
      Junru Lin, Lehong Niu, and Oliver Huang.

   Industrial Machine to Machine (M2M) (Section 7)

      The editor would like to thank Feng Chen and Marcel Kiessling for
      their comments and suggestions.

   Mining industry (Section 8)

      This text was written by Diego Dujovne, who worked in conjunction
      with Xavier Vilajosana.

   Private blockchain (Section 9)

      This text was written by Daniel Huang.

   Network slicing (Section 10)

      This text was written by Xuesong Geng, who would like to
      acknowledge Norm Finn and Mach Chen for their useful comments.

Contributors

   RFC 7322 ("RFC Style Guide") generally limits the number of authors
   listed on the front page of a document to five individuals -- far
   fewer than the 19 individuals listed below, who also made important
   contributions to this document.  The editor wishes to thank and
   acknowledge each of the following authors for contributing text to
   this document.  See also the Acknowledgments section.

      Craig Gunther (Harman International)
      10653 South River Front Parkway
      South Jordan, UT  84095
      United States of America
      Phone: +1 801 568 7675
      Email: craig.gunther@harman.com

      Pascal Thubert (Cisco Systems, Inc.)
      Building D, 45 Allee des Ormes - BP1200
      Mougins - Sophia Antipolis  06254
      France
      Phone: +33 4 97 23 26 34
      Email: pthubert@cisco.com

      Patrick Wetterwald (Cisco Systems)
      45 Allee des Ormes
      Mougins  06250
      France
      Phone: +33 4 97 23 26 36
      Email: pwetterw@cisco.com

      Jean Raymond (Hydro-Quebec)
      1500 University
      Montreal, Quebec  H3A 3S7
      Canada
      Phone: +1 514 840 3000
      Email: raymond.jean@hydro.qc.ca

      Jouni Korhonen (Broadcom Corporation)
      3151 Zanker Road
      San Jose, CA  95134
      United States of America
      Email: jouni.nospam@gmail.com

      Yu Kaneko (Toshiba)
      1 Komukai-Toshiba-cho
      Saiwai-ku, Kasasaki-shi, Kanagawa
      Japan
      Email: yu1.kaneko@toshiba.co.jp

      Subir Das (Vencore Labs)
      150 Mount Airy Road
      Basking Ridge, NJ  07920
      United States of America
      Email: sdas@appcomsci.com

      Balazs Varga (Ericsson)
      Konyves Kalman krt. 11/B
      Budapest  1097
      Hungary
      Email: balazs.a.varga@ericsson.com

      Janos Farkas (Ericsson)
      Konyves Kalman krt. 11/B
      Budapest  1097
      Hungary
      Email: janos.farkas@ericsson.com

      Franz-Josef Goetz (Siemens)
      Gleiwitzerstr. 555
      Nurnberg  90475
      Germany
      Email: franz-josef.goetz@siemens.com

      Juergen Schmitt (Siemens)
      Gleiwitzerstr. 555
      Nurnberg  90475
      Germany
      Email: juergen.jues.schmitt@siemens.com

      Xavier Vilajosana (Worldsensing)
      483 Arago
      Barcelona, Catalonia  08013
      Spain
      Email: xvilajosana@worldsensing.com

      Toktam Mahmoodi (King's College London)
      Strand, London  WC2R 2LS
      United Kingdom
      Email: toktam.mahmoodi@kcl.ac.uk

      Spiros Spirou (Intracom Telecom)
      19.7 km Markopoulou Ave.
      Peania, Attiki  19002
      Greece
      Email: spiros.spirou@gmail.com

      Petra Vizarreta (Technical University of Munich)
      Maxvorstadt, Arcisstrasse 21
      Munich  80333
      Germany
      Email: petra.stojsavljevic@tum.de

      Daniel Huang (ZTE Corporation, Inc.)
      No. 50 Software Avenue
      Nanjing, Jiangsu  210012
      China
      Email: huang.guangping@zte.com.cn

      Xuesong Geng (Huawei Technologies)
      Email: gengxuesong@huawei.com

      Diego Dujovne (Universidad Diego Portales)
      Email: diego.dujovne@mail.udp.cl

      Maik Seewald (Cisco Systems)
      Email: maseewal@cisco.com

Author's Address

   Ethan Grossman (editor)
   Dolby Laboratories, Inc.
   1275 Market Street
   San Francisco, CA  94103
   United States of America

   Phone: +1 415 645 4726
   Email: ethan.grossman@dolby.com
   URI:   http://www.dolby.com