Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt

["Ejzak, Richard P (Richard)" <[e-mail]>]

I have various comments on section 4 of draft-reddy-rtcweb-mobile.

First of all, thanks for this draft as it highlights some issues that will be very important in deployment of WebRTC in LTE and related mobile networks.  I will comment on section 4.2 out of order to avoid forward references in the comments.

4.2: This section makes the assertion that only UE initiated bearer modification procedures are available to a "public WebRTC server". While this is an option in the specification (not necessarily always used), there is also a network API available for the public WebRTC server to be able (if allowed by the mobile network provider) to request QoS for specific flows. There is a Parlay X API for QoS and also plans to develop a RESTful API.

4.1 RTP session multiplexing:

This section is very pessimistic about the ability to assign different bearers to multiplexed flows. I think that solutions do exist, which I describe below.

First, I find the discussion of DSCP markings in the text to be confusing, but I think this is because the text assumes that there is no coordination between the network and the WebRTC application with regard to DSCP markings. While this is strictly true when using UE initiated bearer modification procedures, the situation is a bit more nuanced.

I will discuss handling of the uplink and downlink flows separately.

There should be no problem for either a UE or network initiated bearer modification procedure to specify uplink TFTs including five-tuple and TOS (DSCP). There is no reason to apply network policy to the selection of DSCP values in the uplink TFTs since they will just be remapped in the network anyway. Uplink packets with the corresponding marking will be assigned to the desired bearer for transport over the radio. This assumes that the markings survive transit from the browser to the modem, which should not be a problem within a device or small network. This also assumes that there is no blocking at intermediate queues between the browser and the modem, which might occur, e.g., if different priority flows share a queue for a five-tuple. A proper design will avoid this potential problem. The network will remark the uplink packets according to policy before forwarding them into the backbone to the remote peer, so the design cannot depend on the markings surviving transit through the network. In general, priority treatment on the radio is much more important than priority treatment in the backbone.

Without some additional effort, this approach will fail in the downlink since it is not possible to know how the packets transiting through the network will be marked. The packets can be remarked at any point on the path from their source, so even knowledge of access network marking policies will not help without additional procedures.

There are two possible solutions to this problem, and both require that some mechanism is available to identify the packets belonging to any one flow so that they can be passed to the correct bearer for handling. Fortunately, rtcweb requires that the SSRC(s) for each flow be explicitly signaled in the SDP, thus providing a way of identifying each flow (i.e., filtering on five-tuple and SSRC value).

The two options for using SSRC to direct each downlink flow to the correct bearer are: 1) insert a gateway node within the access network with the explicit purpose of identifying each downlink flow and remarking the packets to match the DSCP value specified in the corresponding downlink TFT; or 2) extend the TFT filtering mechanism to also support matching on SSRC values.

Option 1) requires that the rtcweb application coordinate the markings with the network to ensure that the downlink markings conform to network policy. This will require some interaction between the rtcweb application and the mobile network, potentially using the network initiated bearer modification procedure. Note that the downlink markings can be defined by network policy and the uplink markings can be defined by rtcweb/browser policy, which can be different.

Option 2) requires a modification to the 3GPP specifications to extend the TFT mechanism but is certainly the technically preferred solution since it eliminates the need to be aware of network marking policies and eliminates the need to insert a gateway just for the purpose of remarking packets. Note also that when this extension is available, the uplink TFTs can be based on SSRC as well to eliminate any dependence on packet markings.

Thus there are two workable solutions to providing QoS treatment to multiplexed media flows, one available with existing specifications and one requiring some small 3GPP spec enhancements. The only requirement relevant to rtcweb is that the SSRC values used for different media flows must be explicitly signaled in SDP so that they are available to identify each flow.


4.3, first bullet: What is the practical implication, if any, of delaying the interaction with the PCRF until the 2nd offer/answer?

4.3, second bullet: There should probably be a definition of "WebRTC server" in the document. It's not clear from the text why this and no other entity must have an "Rx" like interface to a PCRF.  It's also not clear why the interface is "Rx" like and not Rx.  There is no question that some entity on the signaling path needs to interact directly or indirectly with the PCRF.

Richard