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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 14 Jan 2013 14:35:33 +0000

Hi all,'

This document describes a set of scenarios in which WebRTC applications have problems in Mobile Networks related to QOS, Mobility (SIPTO). Thanks to Magnus, Markus, Dan and Basavraj for their help and comments. The URL of the new draft:

http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00

comments and suggestions are welcome.

Best Regards,

--authors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 14, 2013 1:40 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]; Ram Mohan R (rmohanr)
Subject: New Version Notification for draft-reddy-rtcweb-mobile-00.txt

A new version of I-D, draft-reddy-rtcweb-mobile-00.txt

has been successfully submitted by Tirumaleswar Reddy and posted to the

IETF repository.

Filename:   draft-reddy-rtcweb-mobile

Revision:   00

Title:            Problems with WebRTC in Mobile Networks

Creation date:    2013-01-14

WG ID:            Individual Submission

Number of pages: 14

URL:             http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-mobile-00.txt

Status:          http://datatracker.ietf.org/doc/draft-reddy-rtcweb-mobile

Htmlized:        http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00

Abstract:

   This document describes a set of scenarios in which WebRTC

   applications have problems in Mobile Networks.

The IETF Secretariat

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jan 2013 15:29:21 -0800

There are many characteristics of mobile networks that make poorly
designed applications perform poorly.  Honestly, WebRTC isn't special
in this regard.  I'd prefer to see something that is less negatively
worded that instead aims to improve awareness of the limitations of
the network and how a well-designed application might avoid the
problems that these cause.  See:
http://developer.android.com/training/efficient-downloads/efficient-network-access.html#RadioStateMachine

For example, I find the assertion that is made here, namely
multiplexing will degrade the quality of experiences, to be specious.
The assertion is true, but it presumes that multiplexing is or must be
used.

--Martin

On 14 January 2013 06:35, Tirumaleswar Reddy (tireddy)
<[email-masked]> wrote:
> Hi all,'
>
>
>
> This document describes a set of scenarios in which WebRTC applications have
> problems in Mobile Networks related to QOS, Mobility (SIPTO). Thanks to
> Magnus, Markus, Dan and Basavraj for their help and comments. The URL of the
> new draft:
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-mobile-00.txt
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 17 Jan 2013 06:30:13 +0000

> The assertion is true, but it presumes that multiplexing is or must be

agree, to go one step further, I don't even agree that it will degrade experience on many networks

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Jan 2013 17:06:18 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: Wednesday, January 16, 2013 10:30 PM
> To: Martin Thomson
> Cc: [email-masked]
> Subject: Re: [rtcweb] New Version Notification for draft-reddy-rtcweb-
> mobile-00.txt
> 
> 

Many networks don't build queues?

-d

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Sun, 20 Jan 2013 06:22:48 +0000

Inline as SD:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, January 16, 2013 3:29 PM
To: Tirumaleswar Reddy (tireddy)
Cc: John Kaippallimalil; [email-masked]; [email-masked]
Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt

There are many characteristics of mobile networks that make poorly designed applications perform poorly.  Honestly, WebRTC isn't special in this regard.  I'd prefer to see something that is less negatively worded that instead aims to improve awareness of the limitations of the network and how a well-designed application might avoid the problems that these cause.  See:
http://developer.android.com/training/efficient-downloads/efficient-network-access.html#RadioStateMachine

For example, I find the assertion that is made here, namely multiplexing will degrade the quality of experiences, to be specious.
The assertion is true, but it presumes that multiplexing is or must be used.

SD: the question is what assumption is made regarding DSCP values for the single UDP flow which has multiplexed RTP flows?
- If the assumption is that multiple DSCP is used for the single flow, then the document states that it does not work in the 3G network. However, the assumption is premature at this stage as it is not a foregone conclusion. On the other hand with this assumption, the user experience should not degrade because it is no different from different flows with their own DSCPs.

- If the assumption is that a single DSCP for a multiplexed flow, then there is a chance that the experience will degrade but then it should not be a problem since the DSCP value in TFT for the bearer should match with the DSCP value in the RTP packets sent by the UE. 

However, if the mobile elements turn down the multiplexing as is suggested by the rtcweb usage draft then either of the above scenarios ceases to exist.
Regards,
Subha

--Martin

On 14 January 2013 06:35, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> applications have problems in Mobile Networks related to QOS, Mobility 
> (SIPTO). Thanks to Magnus, Markus, Dan and Basavraj for their help and 
> comments. The URL of the new draft:
>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 20 Jan 2013 10:22:25 +0000

Hi Subha/Martin,

Thanks for the comments. Please see inline [TR].

> From: Subha Dhesikan (sdhesika)
> Sent: Sunday, January 20, 2013 11:53 AM
> To: Martin Thomson; Tirumaleswar Reddy (tireddy)
> Subject: RE: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-
> mobile-00.txt
> 
> Inline as SD:
> 
> There are many characteristics of mobile networks that make poorly designed
> applications perform poorly.  Honestly, WebRTC isn't special in this regard.
> I'd prefer to see something that is less negatively worded that instead aims
> to improve awareness of the limitations of the network and how a well-designed
> application might avoid the problems that these cause.  See:
> For example, I find the assertion that is made here, namely multiplexing will
> degrade the quality of experiences, to be specious.
> SD: the question is what assumption is made regarding DSCP values for the
> single UDP flow which has multiplexed RTP flows ?

> - If the assumption is that multiple DSCP is used for the single flow, then
> the document states that it does not work in the 3G network. However, the assumption is premature at this stage as it is not a foregone conclusion. 

This is not a problem of just setting DSCP values.

3GPP uses the concept of bearer. Each bearer is associated with a QCI value. For example if we consider a media session with Audio and video media streams. 3GPP has explicit QCI values for each stream : 

[1] QCI value 1 means packet priority (2), packet delay (100ms), packet loss (10 to the power -2) and used for Voice
[2] QCI value 2 means packet priority (2), packet delay (150ms), packet loss (10 to the power -3) and used for Video

In the above scenario two bearers would be required one for audio and the other for video. Each bearer would have to be associated with packet filters (5-tuple) to identify the audio and video media streams. This needs WebRTC application to be aware of QCI/GBR values associated with each stream. The 3GPP network based on the available resources may or may not permit the bearer resource modification request triggered by the UE. If the network does not permit the bearer resource modification then it does not make any difference by setting DSCP values.

These QCI values are mapped by the network to relevant DSCP values. Hence we have recommended in the draft that Mobile devices in 3GPP network should not prefer RTP Multiplexing.
 
> On the other hand with this assumption, the user experience should not degrade
> because it is no different from different flows with their own DSCPs.
> - If the assumption is that a single DSCP for a multiplexed flow, then there
> is a chance that the experience will degrade but then it should not be a
> problem since the DSCP value in TFT for the bearer should match with the DSCP
> value in the RTP packets sent by the UE.

I did not understand your argument. Are you saying though that WebRTC application would request bearer allocation for audio or video stream only but multiplex audio and video streams on the same 5-tuple ?  If so please explain how would it work in this case ?

--Tiru.

> 
> However, if the mobile elements turn down the multiplexing as is suggested by
> the rtcweb usage draft then either of the above scenarios ceases to exist.
> Regards,
> Subha
> 
> --Martin
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 23 Jan 2013 22:49:48 +0000

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 30 Jan 2013 17:30:09 +0000

Sorry for the delay in responding on this thread. Please see comments inline.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ejzak, Richard P (Richard)
> Sent: Wednesday, January 23, 2013 2:50 PM
> To: [email-masked]
> 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.
> 
> 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.
> 
> 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 throu
>  gh 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.

I don't think this is a realistic requirement. It may be feasible in some cases, but it won't work well in others, such as large switched conferences. I recall this subject being discussed in previous meetings. Fortunately I do not find such a requirement in the requirements draft.

Setting that aside, we have media types beyond audio and video for which SSRC are not applicable. I suppose you could assume some default treatment for such media types, but that is pretty limited.
 
Cheers,
Charles

> 
> 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
> 
> 
> 
> 
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 30 Jan 2013 20:33:55 +0000

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]

> I don't think this is a realistic requirement. It may be feasible in some
> cases, but it won't work well in others, such as large switched
> conferences. I recall this subject being discussed in previous meetings.
> Fortunately I do not find such a requirement in the requirements draft.

Well, at least in rtcweb with the explicit signaling of each MSID this requirement is satisfied.  I have suggested a more general solution based on restricted SSRC assignment that I think could work quite well but this was not well received.  

Do you have an alternative solution that does not require some means of signaling how to identify each flow?  And why is it not feasible to add the option to explicitly signal such additional information with an extra offer/answer exchange WHEN necessary to assure proper QoS in the presence of media multiplexing?  

I doubt that it makes sense to use media multiplexing (bundle) for large switched conferences anyway.  If you need complete freedom to create new streams at will then each (unbundled) media type should probably have its own five-tuple and QoS treatment.  This would not preclude the multiplexing of multiple streams of the same media type within a five-tuple, where you get most of the advantages of multiplexing in this case.  But in the vast majority of the cases, users will not have the need for this and could benefit from the benefits of both media multiplexing and QoS.

> Setting that aside, we have media types beyond audio and video for which
> SSRC are not applicable. I suppose you could assume some default treatment
> for such media types, but that is pretty limited.
> 
> Cheers,
> Charles

With regard to other media types, only data channels are relevant in rtcweb.  I am not aware of a general solution to differentiating among data channels outside of the browser since all the SCTP frames are encrypted.  The browser will bear the brunt of the responsibility for differentiating among the transmitted data channels within a five-tuple.  For reasons already discussed, DSCP is at best a partial solution (if even applicable to different flows within an SCTP association, which I have not studied).  As you say, the data channels will receive the same treatment in the network.  And "default" treatment for the data channels can be defined on a five-tuple basis and is not necessarily just "best effort", so this is not as limited as it might seem.  

In the case of other media transport options, we could potentially define yet other filters based on other protocol fields, but clearly that would be out of scope of rtcweb, and arguably much less important than audio and video, particularly since media multiplexing can be disabled for these flows if necessary to request special QoS treatment.

I hope you are not suggesting that since there are difficulties in achieving a 100% general solution that attempts to solve the most important use cases should be abandoned?

Thanks for your comments!
Richard

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 31 Jan 2013 19:41:33 +0000

> From: Ejzak, Richard P (Richard) [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2013 12:34 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Well, at least in rtcweb with the explicit signaling of each MSID this
> requirement is satisfied.  I have suggested a more general solution based on
> restricted SSRC assignment that I think could work quite well but this was
> not well received.
> 
> Do you have an alternative solution that does not require some means of
> signaling how to identify each flow?  And why is it not feasible to add the
> option to explicitly signal such additional information with an extra
> offer/answer exchange WHEN necessary to assure proper QoS in the
> presence of media multiplexing?

I think a level of abstraction is required. For example, if you have 3 video streams, and you want to prioritize the first one over the second and third, the QoS provided could be independent of the SSRC the source of the stream happened to be using at that time. As the SSRC and/or source changes over time (e.g. an active speaker switch or an SSRC collision), the QoS for the first stream remains constant. This seems desirable and does not require explicit signaling of SSRCs. 
If I have a conference with 1000 participants, I do not want to have an offer/answer exchange between the conference server and each participant each time a new participant joins, changes SSRC, or starts/ends being an active speaker). Just imagine how many offer/answer exchanges that would be while the conference was starting up and how large your SDP specifying all those SSRCs would be.
 
> I doubt that it makes sense to use media multiplexing (bundle) for large
> switched conferences anyway.  If you need complete freedom to create
> new streams at will then each (unbundled) media type should probably
> have its own five-tuple and QoS treatment.  This would not preclude the
> multiplexing of multiple streams of the same media type within a five-
> tuple, where you get most of the advantages of multiplexing in this case.
> But in the vast majority of the cases, users will not have the need for this
> and could benefit from the benefits of both media multiplexing and QoS.

Agreed.

Cheers,
Charles

> With regard to other media types, only data channels are relevant in rtcweb.
> I am not aware of a general solution to differentiating among data channels
> outside of the browser since all the SCTP frames are encrypted.  The
> browser will bear the brunt of the responsibility for differentiating among
> the transmitted data channels within a five-tuple.  For reasons already
> discussed, DSCP is at best a partial solution (if even applicable to different
> flows within an SCTP association, which I have not studied).  As you say, the
> data channels will receive the same treatment in the network.  And
> "default" treatment for the data channels can be defined on a five-tuple
> basis and is not necessarily just "best effort", so this is not as limited as it
> might seem.
> 
> In the case of other media transport options, we could potentially define
> yet other filters based on other protocol fields, but clearly that would be
> out of scope of rtcweb, and arguably much less important than audio and
> video, particularly since media multiplexing can be disabled for these flows
> if necessary to request special QoS treatment.
> 
> I hope you are not suggesting that since there are difficulties in achieving a
> 100% general solution that attempts to solve the most important use cases
> should be abandoned?
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 31 Jan 2013 21:25:56 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Thursday, January 31, 2013 11:42 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt

> If I have a conference with 1000 participants, I do not want to have an offer/answer exchange between the conference server
> and each participant each time a new participant joins, changes SSRC, or starts/ends being an active speaker). 
> Just imagine how many offer/answer exchanges that would be while the conference was starting up and how large your 
> SDP specifying all those SSRCs would be.
 
If only there were a way to create an API that didn't require SDP exchanges in order to tell a browser what media to send and with what parameters...

Matthew Kaufman