Subject: [tsvwg] Fwd: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 3 Jul 2014 05:50:53 +0000

David Black asked me to forward my Ops Directorate “early review” of draft-ietf-tsvwg-rtcweb-qos to the list.

As an additional comment, reflecting on comments in other quarters (dart), it may be worthwhile pointing out in the draft that the DSCP indicates a minimum acceptable service level; if a network thinks it can achieve that service level within some larger scheme (such as a traffic class described in Ruediger’s draft, RFC 5127, or simply by oversupplying bandwidth), that is at the operator’s discretion.

Begin forwarded message:

> From: "Fred Baker (fred)" <[email-masked]>
> Subject: Re: [OPS-DIR] Early Ops-Dir review for rtcweb-qos draft
> Date: July 2, 2014 at 11:07:43 AM PDT
> To: "Benoit Claise (bclaise)" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> 
> On Jul 2, 2014, at 9:40 AM, Benoit Claise <[email-masked]> wrote:
> 
>> Hi David,
>> 
>> Fred Baker accepted to review this document for the early Ops-DIR
>> Thanks Fred.
>> Gunter, can you please mark it as such in the in OPS DIR review tool.
>> 
>> Regards, Benoit
>> 
>>> Greetings,
>>> 
>>> On behalf of the tsvwg WG, I'd like to request an early OPS-Dir review of draft-ietf-tsvwg-rtcweb-qos from a network operations perspective:
>>> 
>>> 	http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/
>>> 
>>> Although I'm an OPS-Dir member, I'm looking for a review from someone w/actual network operations expertise, which I freely admit is not me ;-).  The concern that motivates this review is that this draft recommends use of a significant number of Diffserv DSCPs in Section 5:
>>> 
>>> 	http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02#section-5
>>> 
>>> I have input from one large network operator (DT) that this is well off (by a factor of 2 or more) from the number of DSCPs that are (and are likely to be) supported on their network (and other similar networks) for non-internal (e.g., subscriber/customer) traffic, and hence much of the differentiation is likely to vanish on ingress to such a network, if not before.
>>> 
>>> Input from someone else familiar with the QoS aspects of network operations would be rather helpful at this stage.
>>> 
>>> Thanks,
>>> —David
> 
> In fairness, I’m not an operator either. To directly answer David's question, you need an operator to respond.
> 
> I am, however, one of the authors of RFC 4594, which this note quotes, and RFC 5127, which addresses aggregation of those classes in high speed networks. 
> 
> https://tools.ietf.org/html/rfc4594
> 4594 Configuration Guidelines for DiffServ Service Classes. J.
>     Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes)
>     (Updated by RFC5865) (Status: INFORMATIONAL)
> 
> https://tools.ietf.org/html/rfc5127
> 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F.
>     Baker. February 2008. (Format: TXT=43751 bytes) (Status:
>     INFORMATIONAL)
> 
> The heart of the document is section 5, in which it makes specific DSCP recommendations. Were I to try to implement it, I think I would find it confusing and difficult. Color me pedantic, but let me give you the questions that flow through my head as I read it.
> 
> An important statement made here is:
> 
>>   +---------------------------+-------+------+------------+-----------+
>>   |         Data Type         |  Very | Low  |   Medium   |    High   |
>>   |                           |  Low  |      |            |           |
>>   +---------------------------+-------+------+------------+-----------+
>>   |           Audio           |  CS1  |  BE  |  EF (46)   |  EF (46)  |
>>   |                           |  (8)  | (0)  |            |           |
>>          <various other classes and code points>
>>   +---------------------------+-------+------+------------+-----------+
>> 
>>                                  Table 1
>> 
>>   The columns "very low", "low", "Medium" and "high" are the priority
>>   levels.   The browser SHOULD first select the data type of the media
>>   flow.  Within the data type, the priority of the media flow SHOULD be
>>   selected.  All packets within a media flow SHOULD have the same
>>   priority.  [snip]
> 
> RFC 4594 has no corollary concept of “priority” of the data traffic. It focuses on the type of application and that application’s requirements; if it needs to minimize network-induced jitter, it might recommend using a priority scheduler, transferring jitter from EF to other traffic classes, and if it targets TCP traffic, it might recommend the use of AQM technologies. For it, the question is not the relative importance of the session to the user or some other outside observer, but the technology required to deliver the QoS services that the application requires. By comparison, RFC 5865 does discuss precedence classes for sessions; in that case, the question is a service policy that might admit a new session to the network if it is deemed “important” via some authenticated authorization process when it would not admit a new session from just anyone. So I struggle to determine how the browser would decide whether a given session was “very low”, “low”, “medium”, or “high” priority, and what the concept of “priority” means in the context.
> 
> I also struggle to understand the meaning of the reference to “BE”. I presume it means “Best Effort”. RFC 4594 does not describe a “Best Effort” DSCP or traffic class; it does describe “Default”, which I think this is referring to. Similarly, definitions of the Differentiated Services architecture (I haven’t checked all of the 272 specifications that include the text string “Differentiated Services”, but I have reviewed the documents from RFC 2474 through 2999) make no such reference. “Best Effort” is a term describing a characteristic of any datagram network service; packets in flight may be dropped, duplicated, or reordered, as compared with services that enforce in-order and in some cases reliable delivery. I would prefer to see the appropriate traffic class, which I think might be “Default”, used in this document.
> 
> The document also makes a statement that I think is unnecessary:
> 
>   The above table assumes that packets marked with CS1 is treated as
>   "less than best effort".  However, the treatment of CS1 is
>   implementation dependent.  If an implementation treats CS1 as other
>   than "less than best effort", then the priority of the packets may be
>   changed from what is intended.
> 
> With respect, the treatment of every traffic class is implementation-dependent, and every mark is fungible. The document should describe how traffic should be marked, and what traffic so marked expects from the network. The network will then do whatever it thinks is appropriate to satisfy that requirement.
> 
> I would not recommend the adoption or publication of the draft in its present form.
> _______________________________________________
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jul 2014 08:26:32 +1200

Hi Fred,

I agree with your review. Just two remarks inserted below:

> As an additional comment, reflecting on comments in other quarters (dart), it may be worthwhile pointing out in the draft that the DSCP indicates a minimum acceptable service level; if a network th…

Yes. However, EF is a little bit strange in that respect, as I understand
the formal definition. EF is supposed to provide a configured maximum
capacity, and traffic that exceeds that capacity is presumed to be
dropped. So the excess traffic, at least in theory, gets the worst
treatment of all, and the capacity in excess of that configured for
EF is left free for non-EF traffic. That is a bit counter-intuitive
for people who think of EF as the "best" class.

>> RFC 4594 has no corollary concept of “priority” of the data traffic. It focuses on the type of application and that application’s requirements; if it needs to minimize network-induced jitter, it might recommend using a priority scheduler, transferring jitter from EF to other traffic classes, and if it targets TCP traffic, it might recommend the use of AQM technologies. For it, the question is not the relative importance of the session to the user or some other outside observer, but the technology required to deliver the QoS services that the application requires. By comparison, RFC 5865 does discuss precedence classes for sessions; in that case, the question is a service policy that might admit a new session to the network if it is deemed “important” via some authenticated authorization process when it would not admit a new session from just anyone. So I struggle to determine how the browser would decide whether a given session was “very low”, “low”, “
medium”, or “high” priority, and what the concept of “priority” means in the context.
>> With respect, the treatment of every traffic class is implementation-dependent, and every mark is fungible. The document should describe how traffic should be marked, and what traffic so marked ex…

Yes. And specifically, diffserv carefully avoids the primitive idea
of "priority", because that implies simple preemption, which is not
how diffserv works. The text about CS1 presumably intends to refer to
RFC 3662 (A Lower Effort Per-Domain Behavior (PDB) for Differentiated
Services) which is only Informational, but at least gives a complete
description of a specific behaviour called LE, not LBE.

   Brian