Subject: [rtcweb] Comments on draft-ietf-rtcweb-qos-00.txt

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 17 Oct 2012 22:01:15 +0000

Hi!

I have some questions/comments about the draft (which I think is a nice start BTW, :-)!).

Chapter 1
=========

Paragraph 2: "This draft proposes how browser and other VOIP applications...

Question: Addressing also non-browser "apps" widens the scope and this has 
implications on the amount to work that need to be covered to secure 
completeness and correctness. Differences in security model for browser apps
vs other execution environments would need to be addressed. Would it hurt much to
limit the scope to browser *only*?

Paragraph 6: "...defines some input..."

Question: Are the references included in the "some", that is the use of trafficclass
attribute in SDP [6] part of what webRTC should support, e.g. the solution for
the case with site (network) specific DSCP values?

Question: "Some" implies other inputs as well- should this not be an exhaustive list if what governs the browser decision to ensure interoperability 
between different implementations? Or am I missing something?

Chapter 4
=========
Question: I assume the "relative treament" input the Low, Medium and High values in Table 1?

Question: With "session" I understand one PeerConnection instantiation- correct?

Question: The priority indication used by the web app is coming from somewhere- is
this an SDP issue?

Chapter 6
=========
Question: What is the intent of having the LTE QCI Mapping table in the draft? Which
QCI that actually in the end will be associated to the trafficclass attribute is
decided in the cellular network and it is I guess far from for sure one would get that QCI? Also, there are only a limited set of standardised QCI's- there are and will be custom made QCI's out there. Isn't there a risk that by putting it the readers will be lead to believe the web app will get that treatment? Perhaps an "example LTE QCI mapping" is more appropriate?

Comment: The reference to the GBR bearer in LTE leads us into the discussion about
number and value of bw parameters in SDP for Max and Min bw. Perhaps just highlighting that SDP issue/API requirement is in place referring to the appropriate rfc/draft where this will be covered?

Chapter 8
=========
Question: Should not the trafficclass attribute [6] be mentioned here?

Question: Should not the statistics API also include this information?

Chapter 9:
=========
Comment: The need to figure out IP address and port used makes sense but perhaps the background to that requirement could be explained more in the chapters before since it covers sofar only on the use of priority and DSCP?

Comment: I guess one potential risk is a maliceous/poortly written web app
can mess with the trafficclass attribute/priority labeling/bw attribute and 
if the marking in the IP header cannot be trusted, then it will I guess be
discarded in the network, e.g. in the LTE modem receiving the IP packet from the browser when it decides which "QCI" to use- no trust and it ends up on the default bearer, :-).

Many regards
GE

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: den 16 oktober 2012 01:48
> To: [email-masked]
> Cc: [email-masked]
> Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-qos-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
>  This draft is a work item of the Real-Time Communication in 
> WEB-browsers Working Group of the IETF.
> 
> 	Title           : DSCP and other packet markings for RTCWeb QoS
> 	Author(s)       : Subha Dhesikan
>                           Dan Druta
>                           Paul Jones
>                           James Polk
> 	Filename        : draft-ietf-rtcweb-qos-00.txt
> 	Pages           : 10
> 	Date            : 2012-10-15
> 
> Abstract:
>    Many networks, such as Service Provider and Enterprise 
> networks, can
>    provide per packet treatments based on Differentiated Services Code
>    Points (DSCP) on a per hop basis.  This document defines the
>    recommended DSCP values for browsers to use for various classes of
>    traffic.
> 
>    This draft is a very early and far from done.  It is meant 
> to provide
>    the structure for the idea of how to do this but much discussion is
>    needed about the details.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-qos
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtcweb-qos-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>