draft-white-tsvwg-nqb-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

    <!ENTITY RFC8033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8033.xml">
    <!ENTITY RFC8034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8034.xml">
    <!ENTITY RFC8289 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8289.xml">
    <!ENTITY RFC8290 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8290.xml">
    <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">    
    <!ENTITY RFC8325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8325.xml">
    <!ENTITY RFC6817 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6817.xml">
    ]>
    <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
    <!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-white-tsvwg-nqb-02" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

    <!-- ***** FRONT MATTER ***** -->

    <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the 
   full title is longer than 39 characters -->

   <title abbrev="Non Queue Building Flows">Identifying and Handling Non Queue Building Flows in a Bottleneck Link</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Greg White" initials="G." surname="White">
     <organization>CableLabs</organization>
     <address>
       <email>g.white@cablelabs.com</email>
     </address>
   </author>

   <author fullname="Thomas Fossati" initials="T." surname="Fossati">
     <organization>ARM</organization>
     <address>
       <email>Thomas.Fossati@arm.com</email>
     </address>
   </author>


   <date year="2019" />

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

  <!-- Meta-data Declarations -->

  <area>Transport</area>

  <workgroup>Transport Area Working Group</workgroup>


  <keyword></keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

        <abstract>
         <t>This draft proposes the definition of a standardized DiffServ code point (DSCP) to identify Non-Queue-Building flows (for example: interactive voice and video, gaming, machine to machine applications), along with a Per-Hop-Behavior (PHB) that provides a separate queue for such flows.</t>
         <t>The purpose of such a marking scheme is to enable networks to provide and utilize queues that are optimized to provide low latency and low loss for such Non-Queue-Building flows (e.g. shallow buffers, optimized media access parameters, etc.).</t>
         <t>This marking scheme and PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested.  In particular, applications to cable broadband links and mobile network radio and core segments are discussed.</t>   
       </abstract>
     </front>

     <middle>


      <section title="Introduction">

        <t>The vast majority of packets that are carried by broadband access networks are managed by an end-to-end congestion control algorithm, such as Reno, Cubic or BBR.  These congestion control algorithms attempt to seek the available capacity of the end-to-end path (which can frequently be the access network link capacity), and in doing so generally overshoot the available capacity, causing a queue to build-up at the bottleneck link.  This queue build up results in queuing delay that the application experiences as variable latency, and commonly results in packet loss as well.</t>  

        <t>In contrast to traditional congestion-controlled applications, there are a variety of relatively low data rate applications that do not materially contribute to queueing delay and loss, but are nonetheless subjected to it by sharing the same bottleneck link in the access network.  Many of these applications may be sensitive to latency or latency variation, as well as packet loss, and thus produce a poor quality of experience in such conditions.</t>  

        <t>Active Queue Management (AQM) mechanisms (such as <xref target="RFC8033">PIE</xref>, <xref target="RFC8034">DOCSIS-PIE</xref>, or  <xref target="RFC8289">CoDel</xref>) can improve the quality of experience for latency sensitive applications, but there are practical limits to the amount of improvement that can be achieved without impacting the throughput of capacity-seeking applications.</t>

        <t>This document considers differentiating between these two classes of traffic in bottleneck links and queuing them separately in order that both classes can deliver optimal quality of experience for their applications.</t>

        <t>A couple of preconditions need to be satisfied before we can move on from the status quo.  First, the packets must be efficiently identified so that they can be quickly assigned to the "right" queue.  This is especially important with the rising popularity of encrypted and multiplexed transports, which has the potential of making deep inspection infeasible.  Second, the signal must be such that malicious or badly configured nodes can't abuse it. </t>

      </section>
      <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
         document are to be interpreted as described in <xref
         target="RFC2119">RFC 2119</xref>.</t>
      </section>


      <section title="Non-Queue Building Flows">

        <t>There are many applications that send traffic at relatively low data rates and/or in a fairly smooth and consistent manner such that they are highly unlikely to exceed the available capacity of the network path between source and sink.  These applications do not make use of network buffers, but nonetheless can be subjected to packet delay and delay variation as a result of sharing a network buffer with those that do make use of them.  Many of these applications are negatively affected by excessive packet delay and delay variation. Such applications are ideal candidates to be queued separately from the capacity-seeking applications that are the cause of queue buildup, latency and loss.</t>

        <t>These Non-queue-building (NQB) flows are typically UDP flows that send traffic at a lower data rate and don't seek the capacity of the link (examples: online games, voice chat, DNS lookups). Here the data rate is essentially limited by the Application itself.  In contrast, Queue-building (QB) flows include traffic which uses the Traditional TCP or QUIC, with BBR or other TCP congestion controllers. </t>

        <t>There are a lot of great examples of applications that fall very neatly into these two categories, but there are also application flows that may be in a gray area in between (e.g. they are NQB on higher-speed links, but QB on lower-speed links).</t>

      </section>


      <section title="Endpoint Marking and Queue Protection">

        <t>This memo proposes that application endpoints apply a marking, utilizing the Diffserv field of the IP header, to packets of NQB flows that could then be used by the network to differentiate between QB and NQB flows.  It is important for such a marking to be universally agreed upon, rather than being locally defined by the network operator, such that applications could be written to apply the marking without regard to local network policies.</t>

        <t>Some questions that arise when considering endpoint marking are: How can an application determine whether it is queue building or not, given that the sending application is generally not aware of the available capacity of the path to the receiving endpoint?  Even in cases where an application is aware of the capacity of the path, how can it be sure that the available capacity (considering other flows that may be sharing the path) would be sufficient to result in the application's traffic not causing a queue to form?  In an unmanaged environment, how can networks trust endpoint marking, and why wouldn't all applications mark their packets as NQB?</t>

        <t>As an answer the last question, it is worthwhile to note that the NQB designation and marking would be intended to convey verifiable traffic behavior, not needs or wants.  Also, it would be important that incentives are aligned correctly, i.e. that there is a benefit to the application in marking its packets correctly, and no benefit for an application in intentionally mismarking its traffic.  Thus, a useful property of nodes that support separate queues for NQB and QB flows would be that for NQB flows, the NQB queue provides better performance (considering latency, loss and throughput) than the QB queue; and for QB flows, the QB queue provides better performance (considering latency, loss and throughput) than the NQB queue.</t>

        <t>Even so, it is possible that due to an implementation error or misconfiguration, a QB flow would end up getting mismarked as NQB, or vice versa.  In the case of an NQB flow that isn't marked as NQB and ends up in the QB queue, it would only impact its own quality of service, and so it seems to be of lesser concern.  However, a QB flow that is mismarked as NQB would cause queuing delays for all of the other flows that are sharing the NQB queue.</t>

        <t>To prevent this situation from harming the performance of the real NQB flows, network elements that support differentiating NQB traffic SHOULD support a "queue protection" function that can identify QB flows that are mismarked as NQB, and reclassify those flows/packets to the QB queue. This benefits the reclassified flow by giving it access to a large buffer (and thus lower packet loss rate), and benefits the actual NQB flows by preventing harm (increased latency variability) to them.  Such a function SHOULD be implemented in an objective and verifiable manner, basing its decisions upon the behavior of the flow rather than on application-layer constructs.</t>
      </section>


      <section title="Non Queue Building PHB and DSCP">
        <t>This section uses the DiffServ nomenclature of per-hop-behavior (PHB) to describe how a network node could provide better quality of service for NQB flows without reducing performance of QB flows.</t>

        <t>A node supporting the NQB PHB MUST provide a queue for non-queue-building traffic separate from the queue used for queue-building traffic.  This queue SHOULD support a latency-based queue protection mechanism that is able to identify queue-building behavior in flows that are classified into the queue, and to redirect flows causing queue build-up to a different queue.  One example algorithm can be found in Annex P of <xref target="DOCSIS-MULPIv3.1" />.</t>

        <t>While there may be some similarities between the characteristics of NQB flows and flows marked with the Expedited Forwarding (EF) DSCP, the NQB PHB would differ from the Expedited Forwarding PHB in several important ways. <list style="symbols">
          <t>NQB traffic is not rate limited or rate policed.  Rather, the NQB queue would be expected to support a latency-based queue protection mechanism that identifies NQB marked flows that are beginning to cause latency, and redirects packets from those flows to the queue for QB flows.</t>
          <t>The node supporting the NQB PHB makes no guarantees on latency or data rate for NQB marked flows, but instead aims to provide a bound on queuing delay for as many such marked flows as it can, and shed load when needed.</t>
          <t>EF is commonly used exclusively for voice traffic, for which additional functions are applied, such as admission control, accounting, prioritized delivery, etc.</t>
        </list></t>

        <t>In networks that support the NQB PHB, it may be preferred to also include traffic marked EF (0b101110) in the NQB queue.  The choice of the 0x2A codepoint (0b101010) for NQB would conveniently allow a node to select these two codepoints using a single mask pattern of 0b101x10. </t>

  

      </section>

      <section title="End-to-end Support">

        <t>In contrast to the existing standard DSCPs, which are typically only meaningful within a DiffServ Domain (e.g. an AS), this DSCP would be intended for end-to-end usage across the Internet.  Some network operators bleach the Diffserv field on ingress into their network <xref target="Custura"/>, and in some cases apply their own DSCP for internal usage.  Networks that support the NQB PHB SHOULD preserve the NQB DSCP when forwarding via an interconnect.</t>
      </section>


      <section title="Relationship to L4S">
        <t>The dual-queue mechanism described in this draft is intended to be compatible with <xref target="I-D.ietf-tsvwg-l4s-arch"/>.</t>
      </section>

      <section title="Use Cases">
        <section title="DOCSIS Access Networks">
          <t>Residential cable broadband Internet services are commonly configured with a single bottleneck link (the access network link) upon which the service definition is applied.  The service definition, typically an upstream/downstream data rate tuple, is implemented as a configured pair of rate shapers that are applied to the user's traffic.  In such networks, the quality of service that each application receives, and as a result, the quality of experience that it generates for the user is influenced by the characteristics of the access network link.</t>
          <t> To support the NQB PHB, cable broadband services MUST be configured to provide a separate queue for NQB traffic that shares the service rate shaping configuration with the queue for QB traffic.</t>
        </section>

        <section title="Mobile Networks">
          <t>Today's mobile networks are configured to bundle all flows to and from the Internet into a single "default" EPS bearer whose buffering characteristics are not compatible with low-latency traffic.  The established behaviour is partly rooted in the desire to prioritise operators' voice services over competing over-the-top services.  Of late, said business consideration seems to have lost momentum and the incentives might now be aligned towards allowing a more suitable treatment of Internet real-time flows.</t>

          <t>To support the NQB PHB, the mobile network MUST be configured to give UEs a dedicated, low-latency, non-GBR, EPS bearer with QCI 7 in addition to the default EPS bearer; or a Data Radio Bearer with 5QI 7 in a 5G system (see Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping in <xref target="5GSA"/>).</t>

          <t>A packet carrying the NQB DSCP SHOULD be routed through the dedicated low-latency EPS bearer.  A packet that has no associated NQB marking SHOULD be routed through the default EPS bearer.</t>
        </section>

        <section title="WiFi Networks">
          <t> WiFi networking equipment compliant with 802.11e generally supports either four or eight transmit queues and four sets of associated CSMA parameters that are used to enable differentiated media access characteristics. Implementations typically utilize the IP DSCP field to select a transmit queue.</t>  
          <t>As discussed in <xref target="RFC8325"/>, most implementations use a default DSCP to User Priority mapping that utilizes the most significant three bits of the DiffServ Field to select User Priority.  In the case of the 0x2A codepoint, this would map to UP_5 which is in the "Video" Access Category (one level above "Best Effort").</t>
          <t>Systems that utilize <xref target="RFC8325"/>, SHOULD map the 0x2A codepoint to UP_6 in the "Voice" Access Category.</t>
        </section>
      </section>

      <section title="Comparison to Existing Approaches">

        <t>Traditional QoS mechanisms focus on prioritization in an attempt to achieve two goals: reduced latency for "latency-sensitive" traffic, and increased bandwidth availability for "important" applications.  Applications are generally given priority in proportion to some combination of latency-sensitivity and importance.</t>

        <t>Downsides to this approach include the difficulties in sorting out what priority level each application should get (making the value judgement as to relative latency-sensitivity and importance), associating packets to priority levels (configuring and maintaining lots of classifier state, or trusting endpoint markings and the value judgements that they convey), ensuring that high priority traffic doesn't starve lower priority traffic (admission control, weighted scheduling, etc. are possible solutions).  This solution can work in a managed network, where the network operator can control the usage of the QoS mechanisms, but has not been adopted end-to-end across the Internet.  See also <xref target="Claffy" /> for an exhaustive treatment of the argument.</t>

        <t>Flow queueing (FQ) approaches (such as fq_codel <xref target="RFC8290" />), on the other hand, achieve latency improvements by associating packets into "flow" queues and then prioritizing "sparse flows", i.e. packets that arrive to an empty flow queue. Flow queueing does not attempt to differentiate between flows on the basis of value (importance or latency-sensitivity), it simply gives preference to sparse flows, and tries to guarantee that the non-sparse flows all get an equal share of the remaining channel capacity and are interleaved with one another.  As a result, FQ mechanisms could be considered more appropriate for unmanaged environments and general Internet traffic. </t>

        <t>Downsides to this approach include loss of low latency performance due to the possibility of hash collisions (where a sparse flow shares a queue with a bulk data flow), complexity in managing a large number of queues in certain implementations, and some undesirable effects of the Deficit Round Robin (DRR) scheduling. The DRR scheduler enforces that each non-sparse flow gets an equal fraction of link bandwidth, which causes problems with VPNs and other tunnels, exhibits poor behavior with less-aggressive congestion control algorithms, e.g. LEDBAT <xref target="RFC6817" />, and could exhibit poor behavior with RTP Media Congestion Avoidance Techniques (RMCAT) <xref target="I-D.ietf-rmcat-cc-requirements"/>.  In effect, the network element is making a decision as to what constitutes a flow, and then forcing all such flows to take equal bandwidth at every instant.</t>

        <t>The Dual-queue approach defined in this document achieves the main benefit of fq_codel: latency improvement without value judgements, without the downsides.</t>

        <t>The distinction between NQB flows and QB flows is similar to the distinction made between "sparse flow queues" and "non-sparse flow queues" in fq_codel.  In fq_codel, a flow queue is considered sparse if it is drained completely by each packet transmission, and remains empty for at least one cycle of the round robin over the active flows (this is approximately equivalent to saying that it utilizes less than its fair share of capacity).  While this definition is convenient to implement in fq_codel, it isn't the only useful definition of sparse flows. </t>

        <t>The Linux Heavy-Hitter Filter <xref target="HHF" /><xref target="Estan"/> qdisc and the Cisco Dynamic Packet Prioritization <xref target="DPP" /> feature both categorize application flows into "mice" and "elephants", and provide a separate queue that gives high priority to the "mice" flows.  In both of these implementations, the definition of a mice flow is one that falls below a defined number of bytes or packets (respectively).  In essence, the first N bytes or packets of every new flow are queued separately, and given priority over other traffic.  The HHF implementation defaults to using 128KB for N, whereas the DPP documentation discusses using 120 packets.</t>

        <t>This approach is relatively simple to implement, but it is making the wrong distinction between flows.  To illustrate, an hour-long 60 kbps multiplayer online gaming flow sending 60 packets per second would be classified as an elephant after the first 17 seconds using HFF or 2 seconds using DPP, whereas it should be considered as NQB for the entire duration.</t>

        <t>Other dual-queue approaches have been proposed, including some that pair a shallow buffer with a deep buffer, similar to what is described in this draft.  One such design is the "RD" mechanism in <xref target="Podlesny"/> which proposes that applications select either high rate or low delay, with one queue (the high-rate queue) being given a large buffer and a higher scheduling weight, and the other queue (the low-delay queue) being given a short buffer and lower scheduling weight.  This approach is somewhat similar to the NQB PHB, in regards to allowing the application to select between a deep buffer and a shallow one, but it places unnecessary restrictions on the scheduling between the two queues, and doesn't differentiate traffic based on behavior.  Further, the approach doesn't provide any safety valve to prevent malicious or misconfigured flows from causing excessive packet loss in the low delay queue.  Similarly, the "Loss-Latency Tradeoff" approach described in <xref target="I-D.fossati-tsvwg-lola"/> posits that applications should choose between a queue that provides low latency and potentially high loss (i.e. a shallow buffer), and one that provides low loss and potentially high latency (i.e. a deep buffer).  This approach misses that both queuing latency and queuing loss are primarily byproducts of application sending behavior, and by properly segregating applications, no trade-off needs to be made. </t>

      </section>


      <section anchor="Acknowledgements" title="Acknowledgements">
       <t>Thanks to Bob Briscoe, Greg Skinner, Dave Taht, Toke Hoeiland-Joergensen and Luca Muscariello for their review comments.</t>
     </section>

     <!-- Possibly a 'Contributors' section ... -->

     <section anchor="IANA" title="IANA Considerations">
       <t>This draft proposes the registration of a standardized DSCP = 0x2A to denote Non-Queue-Building behavior.</t>
     </section>

     <section anchor="Security" title="Security Considerations">
      <t>There is no incentive for an application to mismark its packets as NQB (or vice versa).  If a queue-building flow were to mark its packets as NQB, it could experience excessive packet loss (in the case that queue-protection is not supported by a node) or it could receive no benefit (in the case that queue-protection is supported).  If a non-queue-building flow were to fail to mark its packets as NQB, it could suffer the latency and loss typical of sharing a queue with capacity seeking traffic.</t> 

      <t>The NQB signal is not integrity protected and could be flipped by an on-path attacker.  This might negatively affect the QoS of the tampered flow. </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->
     &RFC8033;
     &RFC8034;
     &RFC8289;
     &RFC8290;
     &RFC2119;
     &RFC8325;
     &RFC6817;
     <?rfc include="reference.I-D.ietf-tsvwg-l4s-arch" ?>
     <?rfc include="reference.I-D.fossati-tsvwg-lola" ?>     
     <?rfc include="reference.I-D.ietf-rmcat-cc-requirements" ?>

     <reference anchor="HHF" target="https://lwn.net/Articles/577208/">
      <front>
        <title>net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc</title>
        <author fullname="Terry Lam">
          <organization>Google</organization>
        </author>
        <date day="15" month="December" year="2013" />
      </front>
    </reference>

    <reference anchor="Estan" target="https://dl.acm.org/citation.cfm?id=859719">
      <front>
        <title>New directions in traffic measurement and accounting: Focusing on the elephants, ignoring the mice</title>
        <author initials="C." surname="Estan" fullname="Christian Estan">
          <organization>UCSD</organization>
        </author>
        <author initials="G." surname="Varghese" fullname="George Varghese">
          <organization>UCSD</organization>
        </author>
        <date  month="August" year="2003" />
      </front>
      <seriesInfo name="ACM Transactions on Computer Systems" value="Vol.23, Iss.3"/>
    </reference>

    
    <reference anchor="DPP" target="https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html">
      <front>
        <title>Intelligent Buffer Management on Cisco Nexus 9000 Series Switches White Paper</title>
        <author>
          <organization>Cisco</organization>
        </author>
        <date day="6" month="June" year="2017" />
      </front>
    </reference>
    
    <reference anchor="DOCSIS-MULPIv3.1" target="https://specification-search.cablelabs.com/CM-SP-MULPIv3.1">
      <front>
        <title>MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.1-I18-190422</title>
        <author><organization>Cable Television Laboratories, Inc. </organization></author>
        <date year="April 22, 2019" /> 
      </front></reference>

      <reference anchor="Podlesny" target="http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf">
        <front>
          <title>Rd Network Services: Differentiation Through Performance Incentives</title>
          <author initials="M." surname="Podlesny" fullname="Maxim Podlesny" />
          <author initials="S." surname="Gorinsky" fullname="Sergey Gorinsky" />
          <date year="2008" />
        </front>
        <seriesInfo name="SIGCOMM" value=""/>
      </reference>

      <reference anchor="Claffy" target="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2587262">
        <front>
          <title>Adding Enhanced Services to the Internet: Lessons from History</title>
          <author initials="KC" surname="Claffy" fullname="KC Claffy" />
          <author initials="D." surname="Clark" fullname="David D. Clark" />
          <date year="2015" />
        </front>
        <seriesInfo name="TPRC" value=""/>
      </reference>

      <reference anchor="Custura">
        <front>
          <title>Exploring DSCP modification pathologies in mobile edge networks</title>
          <author initials="A." surname="Custura" />
          <author initials="A." surname="Venne" />
          <author initials="G." surname="Fairhurst" />
          <date year="2017" />
        </front>
        <seriesInfo name="TMA" value="" />
      </reference>

      <reference anchor="5GSA">
        <front>
          <title>System Architecture for 5G</title>
          <author><organization>3GPP</organization></author>
        </front>
        <seriesInfo name="TS" value="23.501" />
      </reference>

    </references>

  </back>
</rfc>

<!-- vim: ft=xml tabstop=2 expandtab:
-->