Subject: [Dart] dscp-rtp draft WGLC: Coupled congestion controller text

From: "Black, David" <[email-masked]>
Date: Fri, 22 Aug 2014 17:42:42 -0400

In addition to his helpful comments to the list, Colin Perkins sent me
a private suggestion to double check the DART dscp-rtp draft text against
this requirement in Section 2 of draft-ietf-rmcat-cc-requirements-05.txt
on Congestion Control Requirements For RMCAT:

   9.   Flows managed by this algorithm and flows competing against at a
        bottleneck may have different DSCP[RFC5865] markings depending
        on the type of traffic, or may be subject to flow-based QoS.  A
        particular bottleneck or section of the network path may or may
        not honor DSCP markings.  The algorithm should attempt to
        leverage DSCP markings when they're available.

I think the DART dscp-rtp draft text is ok wrt that RMCAT draft text, as
the RMCAT draft uses the unmodified word "flow" and hence is silent on
presence, absence, and/or scope of multiplexing.  It's also the case that
the DART draft is supposed to document the present state of things,
whereas this RMCAT requirements draft concerns future congestion
control mechanisms.

OTOH, the text in the DART draft on coupled congestion controllers appears
to be somewhat off, as the guideline on avoidance of reordering within the
scope of a common (coupled) congestion controller only applies when all
bottlenecks are assumed to be shared, as opposed to when measurements
are used to detect them.  That makes the second half of the first guideline
bullet in Section 6 too broad, and may suggest some additional edits to
the text on shared bottleneck detection in Section 5.1.

Here are the text changes that should correct this situation:

-- Section 5.1

OLD
   Shared bottlenecks can be detected via correlations of measured
   metrics such as one-way delay.  An alternative approach assumes that
   the set of packets on a single 5-tuple marked with DSCPs that do not
   allow reordering will utilize a common network path and common
   forwarding resources at each network node.
NEW
   Shared bottlenecks can be detected via techniques such as correlation
   of one-way delay measurements across RTP streams. An alternate approach
   is to assume that the set of packets on a single 5-tuple marked with DSCPs
   that do not allow reordering will utilize a common network path and common
   forwarding resources at each network node.

-- Section 6

After:

   o  Should not use different PHBs and DSCPs that allow reordering
      within a single RTP stream.  If this is not done, significant
      network reordering may overwhelm implementation assumptions about
      reordering limits, e.g., jitter buffer size, causing poor user
      experiences, see Section 5.2 above.

OLD
      When a common (coupled)
      congestion controller is used across multiple RTP streams, this
      recommendation against use of PHBs and DSCPs that allow reordering
      applies across all of the RTP streams that are within the scope of
      a single common (coupled) congestion controller.
NEW
      This guideline applies to all of the RTP streams that are within
      the scope of a common (coupled) congestion controller that does not
      use per-RTP-stream measurements for bottleneck detection.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------