<?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 RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC2597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2597.xml">
<!ENTITY RFC2697 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2697.xml">
<!ENTITY RFC2698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2698.xml">
<!ENTITY RFC2998 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2998.xml">
<!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC4594 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4594.xml">
<!ENTITY RFC6184 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6184.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="info" docName="draft-lai-tsvwg-normalizer-02" ipr="trust200902">

  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Normalization Marker for AF PHB Group">
    Normalization Marker for AF PHB Group in DiffServ</title>

    <author fullname="Cheng-Jia Lai" initials="C.J."
            surname="Lai">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>US</country>
        </postal>

        <email>chelai@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Wenyi Wang" initials="W.Y."
            surname="Wang">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>US</country>
        </postal>

        <email>wenywang@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Stan Yang" initials="S."
            surname="Yang">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>US</country>
        </postal>

        <email>stanyang@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Toerless Eckert" initials="T."
            surname="Eckert">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>US</country>
        </postal>

        <email>eckert@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Fred Yip" initials="F."
            surname="Yip">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street></street>

          <city>San Diego</city>

          <region>CA</region>

          <code></code>

          <country>US</country>
        </postal>

        <email>fyip@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="July" year="2013" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>DiffServ AF PHB</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>In DiffServ, preferential dropping of packets in AF PHB groups has long
         been considered beneficial, typically for video flows with discardable packets.
         Unfortunately, the ecosystem of bandwidth contention at congestion is
         very likely to discourage those video endpoints from generating packets
         with lower precedence markings, i.e. they would lose more packets if doing so.
         Thus, to offer an incentive for more collaborative and mutually beneficial
         behaviors of video endpoints in AF PHB groups,
         we propose a Normalization Marker (NM) for traffic conditioning at network edges.
         Deployment of NM will encourage the video endpoints to
         generate finer layers of intra-flow precedence (IFP) with
         discardable packets in more balanced distributions.
       </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>
         Assured Forwarding (AF) Per-Hop Behavior (PHB) groups are described in
         <xref target="RFC2597" />
         (with terminology clarified in <xref target="RFC3260" />)
         for DiffServ (DS) multimedia service classes
         such as realtime video conferencing and on-demand streaming.
         Four AF PHB groups have been defined in <xref target="RFC4594" /> with
         DS codepoint (DSCP): AF1x, AF2x, AF3x and AF4x
         where x=1, 2 or 3 for drop precedence in each independent AF PHB group.
         The DS nodes that support an AF PHB group must set configuration of
         Active Queue Management (AQM) properly w.r.t. those DSCP markings.
         For example, for AF4x PHB group which includes AF41, AF42 and AF43 markings,
         an AQM implementation by Weighted Random Early Detection (WRED)
         should be configured with some drop probabilities and queue thresholds
         such that the packet loss rate of AF41 &lt;= AF42 &lt;= AF43
         on congestion of the queue.
      </t>
      <t>
         For an AF PHB group, a DS boundary node or host in the DS domain should use
         a marking algorithm that properly assigns AF markings of drop precedence
         to all packets w.r.t. the traffic profiles and Service Level Agreements (SLA).
         For example, <xref target="RFC2697" /> and <xref target="RFC2698" />
         use a token-bucket mechanism for metering each stream of packets
         and respectively define "srTCM" and "trTCM" markers,
         to mark packets by the data rate and burst size limit in traffic profiles.
         Those rate-control markers can be useful at DS boundary nodes
         for traffic conditioning <xref target="RFC2475" /> and
         to support IntServ/RSVP traffic over DS regions <xref target="RFC2998" />.
         Multiple markers may be applied to the same stream,
         either on the same or multiple DS nodes along the path.
         For example, srTCM and trTCM can operate in a so-called "color-aware" mode
         such that for each incoming packet that already carries an AF marking,
         the local srTCM/trTCM either keeps the same or lowers the drop precedence
         of that packet by metering.
      </t>
      <t>
         However, modern video codec technologies are being advanced
         not only in coding efficiency (i.e. better compression ratio)
         but also in two key areas for transport on IP networks:
         (1) encoder rate-control and dynamic adaptation;
         (2) ability to generate discardable packets in multiple layers to tolerate
         packet losses in the network without significant degradation of video quality
         observed at the decoder.
         For (1), the encoder dynamically limits its output rate of packets
         into the AF PHB group,
         i.e., the encoder's host is the first DS node equiped with srTCM/trTCM
         if it marks packets in that behavior.
         The next DS node is the first-hop router which may add extra srTCM/trTCM
         to enforce the traffic conditioning or policing
         from the network's perspective.
         Thus, we consider this an incentive for (1) because an encoder using
         a self rate-control is less likely to see packet losses by the network.
         Unfortunately, an incentive for (2) is arguably missing today.
      </t>
      <t>
         To see the missing incentive for (2), consider the following example
         where 2 video flows A and B with rate control are sent in AF4x PHB group.
         Each sends 5Mbps on average with some burstiness, but still
         complies with the rate and burst limit in its traffic profile.
         However, A and B generate packets with AF4x markings
         in different distributions of precentage:
           <list style="empty">
             <t>Flow A
                   <list style="empty">
                     <t>80% or 4Mbps in AF41</t>
                     <t>20% or 1Mbps in AF42</t>
                     <t>&nbsp;0% or 0Mbps in AF43</t>
                   </list>
             </t>
             <t>Flow B
                   <list style="empty">
                     <t>40% or 2Mbps in AF41</t>
                     <t>40% or 2Mbps in AF42</t>
                     <t>20% or 1Mbps in AF43</t>
                   </list>
             </t>
           </list>
         Flow B at above is likely using a more advanced video technology to generate
         multiple layers of discardable video packets, and thus, its distribution
         of AF4x markings looks finer and more balanced.
         That is, flow B acts more friendly to other flows in this AF4x PHB group.
      </t>
      <t>
         Thus, we argue that the ecosystem in practical deployment should
         offer an incentive for flows to behave similarly to what flow B is doing above,
         i.e., on congestion, the AF4x PHB group should try to drop packets in
         the same amount from each flow, while a flow with finer layers of discardable
         packets and/or in a more balanced distribution should be able to benefit
         from its own efforts and see good results in video quality preservation.
      </t>
      <t>
         Unfortunately, this incentive is still missing today.
         Suppose that congestion occurs in the AF4x WRED queue
         where A and B compete for bandwidth and there is no other flow, for simplicity.
         B's packet loss rate is very likely to become higher than A's,
         despite B's effort of acting friendly:
           <list style="symbols">
             <t>If the queue drops 1Mbps in total,
                <list style="empty">
                  <t>A sees &nbsp;0% or 0Mbps loss;</t>
                  <t>B sees 20% or 1Mbps loss (all its AF43 are lost).</t>
                </list>
             </t>
             <t>If the queue drops 4Mbps in total,
                <list style="empty">
                  <t>A sees 20% or 1Mbps loss (all its AF42 are lost);</t>
                  <t>B sees 60% or 3Mbps loss (all its AF42 and AF43 are lost).</t>
                </list>
             </t>
          </list>
      </t>
      <t>
         Thus, to create the missing incentive at above, we propose
         a new "Normalization Marker" (NM) and describe it in this memo.
         NM can be deployed on DS boundary nodes for traffic conditioning
         in practical deployment with AF PHB groups for multimedia service classes.
         In summary, if NM is applied to a DS boundary node for an AF PHB group,
         it re-assigns the AF markings of all packets per flow
         such that the distributions of the AF markings are similar in all flows,
         i.e., it "normalizes" the distributions of AF markings in all flows.
         It also attempts to maintain the original orders of the intra-flow
         drop precedence carried by the input AF markings, as linearly as possible.
         After the AF-marking distributions are normalized, all those flows
         should see very similar packet loss rates at AQM for this AF PHB group
         on congestion of the queue.
         Then, a codec implementation may have better video quality preservation
         on network congestion if it employs a more advanced video technology
         to generate discardable packets with finer markings of drop precedence
         in a more balanced distribution.
      </t>
      <figure align="center" anchor="NMfigOverview">
        <preamble></preamble>
        <artwork align="left">
          <![CDATA[
                            +------------+
                            |  Runtime   |
                            | Statistics |
                            |            V
                        +-------+    +--------+
                        |       |    |        |
        AF-Marked       | Distr.|    |  Norm  |       AF-Marked
      Packet Stream ===>| Meter |===>| Marker |===> Packet Stream
                        |       |    |        |
                        +-------+    +--------+
            ]]>
        </artwork>
        <postamble>Normalization Marker (NM) with AF PHB Group</postamble>
      </figure>
      <t>
         Note that the use of NM is not necessarily limited to video service classes,
         but could be extended to wherever AF PHB groups can be used,
         or to any other PHB groups that require a similar incentive NM can provide.
      </t>
    </section>

    <section title="Background">
      <section title="Video Packets in Structure">
        <t>
           Modern video codec technologies such as
           <xref target="H264">ITU-T H.264/MPEG-4 AVC</xref>
           typically generate a stream of encoded video packets
           with internal structure of data dependency for decoding.
           This has been designed for at least 3 fundamental reasons:
           <list style="symbols">
              <t>
                 Coding Efficiency: An encoder improves its coding efficiency
                 typically by reducing spatial and temporal redundancy of the input.
                 For video, spatial redundancy is reduced by intra-frame
                 motion prediction and compensation, while temporal redundancy
                 refers to inter-frame since a video stream is composed of
                 a sequence of frames or pictures in the temporal order.
                 With motion prediction, a frame can be encoded by referencing
                 some pixels of the picture data that will be decoded earlier
                 either in the same (intra) or another (inter) frame
                 so that it can use significantly fewer bits to encode this frame.
                 The frame where the pixels are referenced by any other frame
                 is thus called a referenced frame in the video stream;
                 for example, Instantaneous Decoding Refresh (IDR) in H.264
                 or Intra (I) frames are typically referenced by subsequential frames,
                 while Predictive (P) frames may be referenced at the encoder's choice,
                 by the Group of Picture (GOP) profile,
                 and/or by some proprietary algorithm in the codec implementation.
              </t>
              <t>
                 Lossy Network: To use network transport that may lose packets,
                 the encoder may choose to generate a stream with two or more layers
                 each of which the packets are marked with some layer identifier (ID).
                 The network can simply use the layer ID to determine
                 the drop precedence of each packet in the video stream.
                 <list style="symbols">
                   <t>Layers in Hierarchy of Dependency:
                      If these layers are coded in hierarchy of dependency,
                      the packets in an "enhancement" layer will depend on 1 or more
                      "base" layers to get decoded without errors, while packets in
                      a base layer without dependency can be independently decoded
                      without errors.
                      <list style="symbols">
                        <t>
                           If some enhancement layer packets are lost, the decoding errors
                           in that picture frame will not stay or cascade to other frames
                           given that no others depend on those lost data.
                           This nice property allows the network to safely drop packets
                           in some enhancement layers, if needed, without badly impacting the
                           video quality at decoder.
                        </t>
                        <t>
                           If some base layer packets are lost, the impact can be severe
                           since these decoding errors will stay in buffer and
                           cascade to all other picture pixels that depend on the lost data
                           to decode in the current and/or a later frame.
                           This impact can last tens of seconds
                           as the video quality continues getting worse,
                           resulting in unpleasant user experiences,
                           until the decoder receives the next IDR or I frame,
                           either on-demand or periodically, to remove those errors.
                        </t>
                      </list>
                      For example, H.264 Annex G defines Scalable Video Coding (SVC)
                      using a 3-dimensional (i.e. spatical, temporal and quality)
                      hierarchy of layer dependency at the encoder's choice,
                      but for simplicity, it also defines a scalar number called
                      Priority ID (PID) in its header so the network could instead use PID,
                      if set by the encoder, to determine drop precedence in the stream.
                   </t>
                   <t>
                      Layers NOT in Hierarchy of Dependency:
                      Sometimes the encoder will generate multiple layers without
                      any dependency between those layers. These mechanisms usually enlarge
                      the amount of encoded video data for vairous purposes.
                      For example,
                      <list style="symbols">
                        <t>Forward Error Correction (FEC) may be used
                           at the encoder to generate extra FEC packets,
                           so that the decoder can tolerate certain amounts of packet losses.
                        </t>
                        <t>Simulcast (i.e. simultaneous multicast)
                           by an encoder will actually generate multiple layers
                           each of which can be transmitted and decoded independently,
                           in parallel by IP or application multicast.
                           Each layer carries video in a different resolution and/or quality.
                           The decoder can choose 1 or more of those layers to receive
                           according to the required, available or detected bandwidth,
                           packet losses, delays, jitter etc. in its network service.
                        </t>
                      </list>
                      With FEC and/or Simulcast, the encoder can still mark the packets
                      with different drop precedence in those layers
                      to better protect the more important data for video quality at decoding
                      when congestion occurs.
                   </t>
                 </list>
               </t>
               <t>
                  In-Band Signaling: An encoded video stream usually carries
                  in-band control messages that are most critical
                  for adequate encoder and decoder behaviors. For example,
                  <list style="symbols">
                    <t>H.264 Annex D defines Supplemental Enhancement Information (SEI),
                       which could also carry proprietary codec parameters.
                       These in-band control signals should be given the highest drop
                       precedence.
                    </t>
                    <t>Real Time Control Protocol (RTCP) carries in-band control messages
                       for Real Time Protocol (RTP) <xref target="RFC3550" />, which
                       is mostly used for realtime multimedia transmission on IP networks.
                       RTCP messages are defined as RTP packets
                       with special payload types in the RTP stream. RTCP packets should
                       be given the highest drop precedence but should receive the same
                       delay/jitter as regular RTP packets in the same stream.
                    </t>
                  </list>
               </t>
             </list>
          </t>
        </section>

      <section anchor="IFP" title="Intra-Flow Precedence (IFP)">
        <t>
           For abstraction, we define "Intra-Flow Precedence" (IFP) to represent
           the drop precedence in one individual flow that may
           carry a video stream of IP packets in multimedia networks.
           Here is a summary of IFP characteristics:
           <list style="symbols">
              <t>IFPs are drop precedence levels that are only significant
                 within each individual flow.
              </t>
              <t>IFPs are integer numbers that can be numerically compared if needed.
                 0 represents the highest precedence. The larger numerical value an IFP is,
                 the lower precedence it represents.
              </t>
              <t>The number of IFP levels in each flow is not necessarily the same.
              </t>
              <t>IFPs between any 2 flows should NOT be compared
                 to determine drop precedence between their packets in a queue.
              </t>
              <t>IFPs may be assigned by the original encoder of the stream and
                 carried in some bits field of all packets in the stream.
              </t>
              <t>IFPs may be assigned or re-assigned by a middle box or router
                 if it is capable of understanding the stream packet format
                 and codec symantics.
              </t>
           </list>
        </t>
        <t>
           For example, an H.264 AVC flow may have the following IFP assignments
           at the video encoder's choice.
           <list style="empty">
              <t>IFP = 0 for in-band signals</t>
              <t>IFP = 1 for IDR frames</t>
              <t>IFP = 2 for referenced P (rP) frames</t>
              <t>IFP = 3 for non-referenced P (nrP) frames and others</t>
           </list>
        </t>
        <t>
           IFP assignements as well as their distribution can vary a lot
           among different encoder implementations and codec profiles.
           For example, some encoders may generate both long-term and
           short-term referenced P frames, where a long-term referenced P frame
           should have higher drop precedence.
           In case of H.264 SVC, the IFP assignments could simply be the same
           as the PID assignments if set by the encoder properly, or be calculated
           based on the SVC layer ID that has 3 tuples for the spatial, temporal and
           quality dimensions, respectively.
        </t>
      </section>

      <section anchor="MapIFPtoAF" title="Mapping IFP to AF Markings">
        <t>
           When a flow is sent in an AF PHB group, the number of its IFP levels
           is not necessarily equal to the number of the AF markings. In fact,
           since each of the currently defined AF PHB groups has only 3 AF markings,
           it is likely that an encoder or DS node needs to apply an n-to-1 mapping
           from IFPs to AF markings in practice.
        </t>
        <t>The mapping decision is made usually by the encoder, but can also be made
           by another DS node if necessary and if the DS node is able to understand
           the encoded video packets, which may require Deep Packet Inspection (DPI),
           e.g. to read in RTP payload and parse the H.264 headers
           <xref target="RFC6184" />,
           or in a proprietary bits field in the IP payload,
           to retrieve or calculate the IFP of each packet
           in a flow before locally mapping the IFP to an AF marking.
        </t>
        <t>
           This n-to-1 mapping can be arbitrary but should be appropriate.
           Consider 2 IFPs, say x and y, where x and y are mapped to AF markings
           AF(x) and AF(y), respectively.
           Then, the mapping should ideally obey the following criteria
           to keep linearity from IFPs to AF markings.
           <list style="empty">
              <t>If x &lt; y, AF(x) &lt;= AF(y);</t>
              <t>If x &gt; y, AF(x) &gt;= AF(y).</t>
           </list>
           Although the above two do NOT imply that if x = y, AF(x) = AF(y),
           it is usually so in practical implementation as it is straightforward.
           Then, if the encoder algorithm generates a lot of packets with the same IFP,
           all those packets will be assigned the same AF marking,
           possibly resulting in an unbalanced distribution of AF markings
           in the AF PHB group. Thus, an encoder with advanced technologies
           should make good efforts to generate packets with a finer and more balanced
           IFP distribution in the first place.
        </t>
        <t>
           For example, if AF4x PHB group is used to send an H.264 AVC flow
           with the IFP assignments in the example of <xref target="IFP" />,
           one possible IFP-to-AF4x mapping is:
           <list style="empty">
             <t>AF(0) = AF41</t>
             <t>AF(1) = AF41</t>
             <t>AF(2) = AF42</t>
             <t>AF(3) = AF43</t>
           </list>
           This mapping actually results in the following AF markings:
           <list style="empty">
              <t>AF41 for in-band signals and IDR frames</t>
              <t>AF42 for referenced P (rP) frames</t>
              <t>AF43 for non-referenced P (nrP) frames and others</t>
           </list>
           Now, consider two encoders that generate flow A and B, respectively,
           both using this mapping, but with different IFP distributions as follows.
           <list style="empty">
             <t>Flow A
               <list style="empty">
                 <t>&nbsp;5% in IFP=0 for in-band signals</t>
                 <t>75% in IFP=1 for IDR frames</t>
                 <t>20% in IFP=2 for rP frames</t>
               </list>
             </t>
             <t>Flow B
               <list style="empty">
                 <t>&nbsp;5% in IFP=0 for in-band signals</t>
                 <t>35% in IFP=1 for IDR frames</t>
                 <t>40% in IFP=2 for rP frames</t>
                 <t>20% in IFP=3 for nrP frames</t>
               </list>
             </t>
           </list>
           Thus,
           <list style="empty">
             <t>Flow A
                   <list style="empty">
                     <t>80% in AF41</t>
                     <t>20% in AF42</t>
                     <t>&nbsp;0% in AF43</t>
                   </list>
             </t>
             <t>Flow B
                   <list style="empty">
                     <t>40% in AF41</t>
                     <t>40% in AF42</t>
                     <t>20% in AF43</t>
                   </list>
             </t>
           </list>
           This results in exactly the two AF marking distribtions
           that we have previously used in <xref target="intro" />.
        </t>
        <t>
           Note that in terms of encoded data size,
           an IDR frame is typically 10 times larger than a P frame on average.
           Assume that flow B's coding efficiency has rP twice as large as nrP.
           Then, flow A and B might be sending frames periodically in patterns by
           Group of Picture (GOP) as follows:
           <list style="empty">
             <t>Flow A: IDR, rP, rP, rP</t>
             <t>Flow B: IDR, rP, nrP, rP, nrP, rP, nrP, rP, nrP</t>
           </list>
           If so, it shows that flow B's encoder is making efforts to generate
           discardable packets with more layers in a more balanced distribution,
           which is desirable.
        </t>
      </section>
    </section>

    <section anchor="NM" title="Normalization Marker (NM)">
      <t>
         Referring to <xref target="NMarchitecture" />, NM has 3 major components:
           IFP reconstructor,
           IFP distribution meter, and
           normalizer.
         NM may operate in either "color-aware" (CA) or "color-blind" (CB) mode.
      </t>

      <figure align="center" anchor="NMarchitecture">
        <preamble></preamble>
        <artwork align="left">
          <![CDATA[
     +---------------+    +--------------+    +------------+
     |               |    |              |    |            |
     |      IFP      |    |     IFP      |    |            |
 ===>| Reconstructor |===>| Distribution |===>| Normalizer |===>
     |  in CA or CB  |    |    Meter     |    |            |
     |               |    |              |    |            |
     +---------------+    +--------------+    +------------+
            ]]>
        </artwork>
        <postamble>Normalization Marker (NM) Architecture</postamble>
      </figure>

      <t>
         The packets arrive at the IFP reconstructor which determines the IFP
         of each packet depending on whether NM is in CA or CB mode.
         This is fed into the IFP distribution meter that keeps a runtime statistics.
         Then, by the runtime statistics and the IFP of the very packet,
         the normalizer writes a proper AF-marking in that packet.
      </t>

      <section anchor="NMmodes" title="Color-Aware vs. Color-Blind Mode">
        <t>
           When NM operates in "color-aware" (CA) mode, it reads the incoming AF-markings
           that are carried in the packets as the drop precedence. This CA mode
           should be supported in all NM implementations.
        </t>
        <t>
           When NM operates in "color-blind" (CB) mode, which is optionally supported,
           it reads certain bits field(s) other than the AF-markings in the packets
           to determine the actual drop precedence of that packet. This implies that
           NM may need DPI in the packets, e.g. parsing into H.264 AVC header in each
           RTP packets, or alternatively use some method where the drop precedence is
           carried from the encoder in a customized bits field other than the AF-marking
           in each packet.
        </t>
        <t>
           In comparison, CB is more complex than CA in implementation.
           However, CB could probabily produce better normalization results
           because the AF-markings are actually outcomes of an n-to-1 mapping from IFPs,
           as previoulsy mentioned in <xref target="MapIFPtoAF" />,
           which can reduce granularity, e.g. for IFPs x and y, if x > y at encoder,
           it is possible that AF(x) = AF(y) when NM sees those packets in CA mode.
           On the contrary, NM in CB mode may reconstruct IFPs x > y for those packets
           by local DPI.
        </t>
        <t>
           Note that NM in CB mode may fail to determine the IFP of a packet
           for various reasons at runtime.
           If so, NM should randomly assign an IFP to each of those packets
           with an even distribution over the IFPs.
           The failure could be due to payload encryption that prevents DPI.
           Another reason may be that the NM does not support the codec used for
           encoding those packets in the flow.
           For example, an NM might only support H.264 AVC but is unable to parse
           packets in H.264 Annex G (SVC), so it fails to determine the IFPs of packets
           in an H.264 SVC flow.
        </t>
      </section>

      <section anchor="NMdistrMeter" title="Distribution Meter">
        <t>
           The IFP distribution meter keeps a runtime statistics of the IFPs
           per flow so that the normalizer will be able to assign a proper AF-marking
           for each packet. The types of statistics to collect at runtime
           depend on the NM algorithm in the implementation.
        </t>
        <t>
           For example, an NM implementation may keep a counter of packets
           per IFP in a flow since the beginning of the flow's lifetime.
           Another implementation may choose to keep only the running average
           of the packet counter per IFP. An even simpler implementation may
           choose to keep only the running average of IFPs of all packets per flow.
        </t>
      </section>

      <section anchor="NMnormalizer" title="Normalizer">
        <t>
           The normalizer should reference the runtime statistics kept by the
           IFP distribution meter, and adaptively map the IFP of the very packet
           to an AF marking, such that the resulting AF-marking distributions
           for all flows are similar or even identical to a target distribution.
        </t>
        <t>
           The target distribution of an NM can be simply an even distribution
           over all possible AF-markings in the AF PHB group. However,
           in a more complex NM implementation, it may allow configuration for
           other target distributions as appropriate with the AQM configuration.
        </t>
      </section>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank many colleagues for comments and supports,
         and thank Shuai Dai for testing NM with actual H.264 video endpoints.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This memo has no security consideration at the time of writing. </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
      &RFC2475;

      &RFC2597;

      &RFC2697;

      &RFC2698;

      &RFC2998;

      &RFC3260;

      &RFC4594;
    </references>

    <references title="Informative References">
      &RFC3550;

      &RFC6184;

      <reference anchor="H264">
        <front>
          <title>Advanced video coding for generic audiovisual services</title>

          <author>
            <organization>ITU-T Recommendation H.264</organization>
          </author>

          <date month="March" year="2010" />
        </front>
      </reference>
    </references>

  </back>
</rfc>
