[Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?

[Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?

[Dave Taht]

Damned if I know how or if this is going to work.


---------- Forwarded message ----------
From: Black, David <david.black@emc.com>
Date: Tue, Jul 7, 2015 at 8:10 PM
Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
To: "tsvwg@ietf.org" <tsvwg@ietf.org>


<WG chair hat OFF>

This message is written as an individual contributor to engender
some discussion on this topic prior to the TSVWG meetings in Prague.

A significant concern with the WebRTC QoS draft is the large number
of DSCPs that it uses - see Table 1 in Section 5 of the draft:

https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-04#section-5

The WebRTC QoS draft references RFC 4594, which is the foundational
RFC on overall application of Diffserv to various types of traffic.

However, RFC 4594:

        a) is a "Guidelines" RFC, not a "Requirements" RFC;
        b) is not standards track for some very good reasons, so
                the reference to it is a downref; and
        c) explicitly anticipates deployment of subsets of its
                classes in the introduction to the RFC.

Some more recent relevant guidance can be found in the DART draft
that was approved by the IESG last year:

        https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10

Based on that draft, here are a couple of specific concerns that
apply to Table 1 in the WebRTC QoS draft:

- The use of CS1 for Lower Effort (less than best effort) QoS is on
        shaky ground at best.  See the discussion here:

        https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10#page-9

        Also, a discussion on what to do about Diffserv Lower Effort
        (less than best effort) a/k/a Scavenger class QoS is planned
        for TSVWG in Prague.  IMHO, there is a good 20/20 hindsight
        (NB: hindsight) argument to be made that CS1 was the wrong
        Default DSCP to use.

- For data, the WebRTC QoS draft uses four different sets of DSCPs
        across which there are no constraints on reordering:

   |            Data           |  CS1  |  DF  | AF1x (10,  | AF2x (18, |
   |                           |  (8)  | (0)  |  12, 14)   |  20, 22)  |

        This is asking for trouble if all the data involved flows over a
        single SCTP association ... which appears to be exactly what WebRTC
        is going to do:

        https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6

        Something is definitely wrong here, as the DART draft clearly advises
        against more than one DSCP per SCTP association (from Section 6):

   o  Should use a single DSCP for all packets within a reliable
      transport protocol session (e.g., TCP connection, SCTP
      association) or DCCP connection (see Section 5.1 and Section 5.3).
      For SCTP, this requirement applies across the entire SCTP
      association, and not just to individual streams within an
      association.

        Please note that both the DART draft and draft-ietf-rtcweb-data-channel
        are IESG-approved and at the RFC Editor.

In contrast, I think the 9 boxes in Table 1 of WebRTC QoS draft for
Audio, Interactive Video, and  Non-Interactive Video across the Low,
Medium and High API priorities are probably ok, although I think there
needs to be a much stronger warning about confining a media flow to
a single API priority, especially Low (based on the selected DSCPs,
mixing Medium with High in a single type of media flow is ok, but Low
SHOULD NOT be mixed with anything else).

I think that those 9 boxes are the core of the WebRTC QoS draft, so I'm
not suggesting a "tear it up and start over" approach, but I cannot
support an assertion that the table in Section 5 of the WebRTC QoS is
solidly grounded in IETF Diffserv RFCs.

</WG chair hat OFF>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: [Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?

[Mikael Abrahamsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5170 bytes --]


I agree, that's why I have suggested they use CS0 and have new DSCP 
patterns (not currently standardized) and use 000xx0 where xx discerns 
different priority, one being scavanger, one being slightly higher BE (BE+ 
perhaps) and then one could assure the BE+ got 60% of the bw, BE got 30%, 
and BE- (the scavanger class) wasn't assured more than 10% of the bw.

This would have higher chance of being incrementally deployable than any 
of the below suggestions.

On Sat, 18 Jul 2015, Dave Taht wrote:

> Damned if I know how or if this is going to work.
>
>
> ---------- Forwarded message ----------
> From: Black, David <david.black@emc.com>
> Date: Tue, Jul 7, 2015 at 8:10 PM
> Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
> To: "tsvwg@ietf.org" <tsvwg@ietf.org>
>
>
> <WG chair hat OFF>
>
> This message is written as an individual contributor to engender
> some discussion on this topic prior to the TSVWG meetings in Prague.
>
> A significant concern with the WebRTC QoS draft is the large number
> of DSCPs that it uses - see Table 1 in Section 5 of the draft:
>
> https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-04#section-5
>
> The WebRTC QoS draft references RFC 4594, which is the foundational
> RFC on overall application of Diffserv to various types of traffic.
>
> However, RFC 4594:
>
>        a) is a "Guidelines" RFC, not a "Requirements" RFC;
>        b) is not standards track for some very good reasons, so
>                the reference to it is a downref; and
>        c) explicitly anticipates deployment of subsets of its
>                classes in the introduction to the RFC.
>
> Some more recent relevant guidance can be found in the DART draft
> that was approved by the IESG last year:
>
>        https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10
>
> Based on that draft, here are a couple of specific concerns that
> apply to Table 1 in the WebRTC QoS draft:
>
> - The use of CS1 for Lower Effort (less than best effort) QoS is on
>        shaky ground at best.  See the discussion here:
>
>        https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10#page-9
>
>        Also, a discussion on what to do about Diffserv Lower Effort
>        (less than best effort) a/k/a Scavenger class QoS is planned
>        for TSVWG in Prague.  IMHO, there is a good 20/20 hindsight
>        (NB: hindsight) argument to be made that CS1 was the wrong
>        Default DSCP to use.
>
> - For data, the WebRTC QoS draft uses four different sets of DSCPs
>        across which there are no constraints on reordering:
>
>   |            Data           |  CS1  |  DF  | AF1x (10,  | AF2x (18, |
>   |                           |  (8)  | (0)  |  12, 14)   |  20, 22)  |
>
>        This is asking for trouble if all the data involved flows over a
>        single SCTP association ... which appears to be exactly what WebRTC
>        is going to do:
>
>        https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6
>
>        Something is definitely wrong here, as the DART draft clearly advises
>        against more than one DSCP per SCTP association (from Section 6):
>
>   o  Should use a single DSCP for all packets within a reliable
>      transport protocol session (e.g., TCP connection, SCTP
>      association) or DCCP connection (see Section 5.1 and Section 5.3).
>      For SCTP, this requirement applies across the entire SCTP
>      association, and not just to individual streams within an
>      association.
>
>        Please note that both the DART draft and draft-ietf-rtcweb-data-channel
>        are IESG-approved and at the RFC Editor.
>
> In contrast, I think the 9 boxes in Table 1 of WebRTC QoS draft for
> Audio, Interactive Video, and  Non-Interactive Video across the Low,
> Medium and High API priorities are probably ok, although I think there
> needs to be a much stronger warning about confining a media flow to
> a single API priority, especially Low (based on the selected DSCPs,
> mixing Medium with High in a single type of media flow is ok, but Low
> SHOULD NOT be mixed with anything else).
>
> I think that those 9 boxes are the core of the WebRTC QoS draft, so I'm
> not suggesting a "tear it up and start over" approach, but I cannot
> support an assertion that the table in Section 5 of the WebRTC QoS is
> solidly grounded in IETF Diffserv RFCs.
>
> </WG chair hat OFF>
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
>
> -- 
> Dave Täht
> worldwide bufferbloat report:
> http://www.dslreports.com/speedtest/results/bufferbloat
> And:
> What will it take to vastly improve wifi for everyone?
> https://plus.google.com/u/0/explore/makewififast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se