[Aeon] Comments on draft-conet-aeon-problem-statement-00

["Pal Martinsen (palmarti)" <[e-mail]>]

Hi all,

Thanks to the authors for writing this up. I think this is a huge step in the right direction. Fairly short and easy to read.

Below are my comments. (I accidentally pulled the last version from https://github.com/Draft-Mafia/IETF-drafts/tree/master/AEON-Problem-Statement, so all my comments are to that version, not the 00 draft. But they are fairly similar and I only have fairly general comments at this stage.)


Abstract

   Identification and treatment of application flows are important to
   many application providers and network operators.  They often rely on
   these capabilities to deploy and/or support a wide range of
   applications.  These applications, and the packet flows they generate
   and consume, may have specific connectivity requirements that can be

.. specific flow requirements, such as latency, bandwidth and so on that can be ..

To me connectivity is to vague, but might cover it.

   met if made known to the network.  Historically, this functionality
   has been implemented to the extent possible using heuristics, which
   inspect and infer flow characteristics.  Heuristics may be based on
   port ranges, network separation (e.g. subnets or VLANs, Deep Flow
   Inspection (DFI), or Deep Packet Inspection (DPI).  But many
   application flows in current usages are dynamic, adaptive, time-
   bound, encrypted, peer-to-peer, asymmetric, used on multipurpose
   devices, and have different priorities depending on direction of
   flow, user preferences, and other factors.  Any combination of these
   properties renders heuristic based techniques less effective and may
   result in compromises to application security or user privacy.


Are we planning to cover feedback from network to application (Something ECN like) as well? To me this is an equally important part as it enables clients to adopt to changing network conditions. Thus maximising the usefulness of the network. For example rate limiting mechanisms that exist today might react in a much more precise and predictable way.

I see that Req-4 covers somewhat covers that. I would like to add some wording regarding notification for changed network conditions or something similar.


Table of Contents

   1.  Introduction
   2.  Typical Workflows
   3.  Limitations of Heuristic Based Solutions
   4.  Limitations of Existing Signaling Mechanisms
   5.  Efforts in Progress
   6.  Requirements
   7.  Acknowledgements
   8.  Informative References
   Authors' Addresses

1.  Introduction

   Networks today, whether public or private, are challenged with
   demands to support rapidly increasing amounts of traffic.  New
   channels for creating and consuming rich media are deployed at a
   rapid pace.  Pervasive video and access on demand are becoming second
   nature to consumers.  Communication applications make extensive use
   of rich media, placing unprecedented quality of experience
   expectation on the underlying network.  These trends present
   challenges for network forecast and planning operations.

   Now more so than ever before, identification and treatment of
   application flows are critical for the successful deployment and
   operation of a growing number of business and household applications.
   These applications are based on wide range of signaling protocols and
   deployed by a diverse set of application providers that is not
   necessarily affiliated with the network providers across which the
   applications are used.

Should we mention the SDN trend here as well? This have the potential to make SDN networks more powerful and easier to manage for the controller. The more exact flow information the SDN controller can chew on, the better the result.

   Historically, identification of application flows has been
   accomplished using heuristics, which infer flow characteristics based
   on port ranges, network separation, or inspection of the flow itself.
   Inspection techniques include DPI, which matches against
   characteristic signatures (e.g. key string, binary sequence, etc.)
   and DFI, which analyzes statistical characteristics and connection
   behavior of flows.  Each of these techniques suffers from a set of
   limitations, particularly in the face of the challenges on the
   network outlined previously.

Again having ECN like information going back to the client would be nice. Some feedback regarding available bandwidth would also be nice. But not as a “hard” reservation as done with RSVP. Just getting a hint would make clients much more robust in selection an appropriate sending rate for sits media.

   Heuristic-based approaches may not be efficient and require
   continuous updates of application signatures.  Port based solutions
   suffer from port overloading and inconsistent port usage.  Network
   separation techniques like IP subnetting are error prone and increase
   network management complexity.  DPI and DFI are computationally
   expensive, prone to error, and become more challenging with greater
   adoption of encrypted signaling and secured media.  An additional
   drawback of DPI and DFI is that any insights are not available, or
   need to be recomputed, at network nodes further down the application
   flow path.

   As the IETF establishes default behaviors that thwart pervasive
   surveillance (e.g.  [RFC7258]), it will be important to provide
   mechanisms for applications that want to have the network provide
   differential flow treatment for their data.  The intent is to have
   applications protect the contents of their flows, yet have the
   ability to opt-in to information exchanges that provide a more
   precise allocation of network resources and thus a better user
   experience.


Yes. And it is important to standardise this to avoid unwanted information leakage. We should probably add a sentence or two regarding that.

2.  Typical Workflows

   Various heuristic based approaches are used prevalently and
   successfully for the following workflows:

   1.  Provide network operators with visibility of traffic usage and
       patterns for troubleshooting, capacity planning, and other off
       network workflows.  This is done by exporting observed traffic
       analysis via standard protocols such as IPFIX [RFC7011] and SNMP
       [RFC3416]as well as by proprietary protocols and methods.

   2.  Provide network operators with visibility of application and data
       usage for accounting and billing.

   3.  Provide differentiated network services for specific traffic
       according to network operator defined policies, including traffic
       classification, policing and shaping (e.g.  [RFC2475]), providing
       admission control (e.g.  [RFC6601]), impacting routing, and
       permitting passage of specific traffic (e.g. firewall functions).

4.   Provide network feedback to the client. This data can be used by the client to improve rate adopting schemes, and might also provide better hints on how much bandwidth a client can expect to send through the network. (RMCAT WG might chime in here)

3.  Limitations of Heuristic Based Solutions

[cut]

4.  Limitations of Existing Signaling Mechanisms

   The IETF has standardized several mechanisms involving explicit
   signaling between applications and the network that may be used to
   support visibility and differentiated network services workflows.
   Unfortunately, none of these has experienced widespread deployment
   success, nor are they well suited for the applications usages
   described previously.  Existing signaling options include the
   following:

   o  RSVP [RFC2205] is the original on-path signaling protocol
      standardized by the IETF.  It is transported out-of-band and could
      be used to signal information about any transport protocol traffic
      (it currently supports TCP and UDP).  Its original goal was to
      provide admission control.  Its requirement for explicit
      reservation of resources end to end proved too heavy for most
      network environments.  Its success was further impacted by its
      reliance on router-alert, which often leads to RSVP packets being
      filtered by intervening networks, and by its requirement for
      access to a raw socket, something that is generally not available
      to applications running in user space.  To date, more lightweight
      signaling workflows utilizing RSVP have not been standardized
      within the IETF.

   o  NSIS (next Steps in Signaling) [RFC5978] is the next iteration of
      RSVP-like signaling defined by the IETF.  It focused on the same
      fundamental workflow as RSVP admission control as its main driver,
      and because it did not provide significant enough use-case
      benefits over RSVP, it has seen even less adoption than RSVP.

   o  DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet
      marking can help provide QoS in some environments, but such
      markings are often modified or removed at various points in the
      network or when crossing network boundaries.  There are additional
      limitations when using DiffServ with real-time communications
      applications, and the DART working group has been chartered to
      write a document that explains the limitations that exist with
      DiffServ when used with RTP in general as well in the specific
      RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements].

And if we are doing network to client feedback.

 * ECN. Only works for TCP. Same problems as DSCP. Difficult for applications to get access to information in the TCP header or IP header.

5.  Efforts in Progress


[cut]

6.  Requirements

   Rather than encourage independent, protocol specific solutions to
   this problem, this document advocates a protocol and application
   independent information model and individual data models that can be
   applied in a consistent fashion across a variety of protocols to
   enable explicit communication between applications and the networks
   on which they are used.  The requirements are:

   Req-1:  Allow applications to explicitly signal their flow
      characteristics to the network.

   Req-2:  Provide network nodes visibility to application flow
      characteristics.

   Req-3:  Enable network nodes to contribute to application flow
      descriptions.

   Req-4:  Allow applications to receive resulting flow descriptions as
      feedback from the network.

Req-4b: Allow application to receive notifications regarding changing network conditions?

   Req-5:  Complement existing heuristic based mechanisms.

   Req-6:  Provide differentiated service for both directions of a flow,
      including flows that cross administrative boundaries.

   Req-7:  Provide mechanism to authenticate and authorize endpoints/
      applications to signal flow characteristics, including 3rd party
      authentication and authorization for over-the-top (OTT)
      applications.

   Req-8:  Provide mechanism for integrity protection and replay
      protection of messages exchanged between the application and the
      network.


.-.
Pål-Erik