Subject: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"?

From: <[email-masked]>
Date: Tue, 18 Sep 2012 08:07:48 +0000

Hi,

Martin Thomson wrote:
>
>On 10 September 2012 07:15, Harald Alvestrand <[email-masked]>
>wrote:
>> - Pointers to documentation on how browsers are expected to be able to
>> set QCI and WiFI markings would be a good addition. Compared to those,
>> DSCP codepoint setting is well understood.
>
<snip>
>
>What do people think about NOT including QCI/WiFi markings?  Is it not
>possible for a wireless interface to examine DSCP markings in order to
>determine the markings for the link?  We should endeavour to maintain the
>proper abstractions.
>

I'm not even sure if the browser or even the OS can influence much the QCI or bearer selection in LTE. I think the model is such that the "network" sets up these special non-best-effort bearers, and gives the endpoint the classifier rules related to them. The rules tell the endpoint how to map outgoing packets to the bearers. Typically the rules are based on source/destination IP and port, and the transport protocol. Someone may be able to confirm, but I believe DSCP can be used too. But basically the rules come from the network and the endpoint just follows them. 

So, somehow the browser or the JS app would first have to convince the access network provider to setup the special bearer so that the right flows get classified to it. In IMS the SIP proxy reads the SDP and tells some network element what audio or video flows are being setup and what their 5-tuples are, so the network is being able to setup the bearers correctly for them. The endpoint merely waits for this setup and acts accordingly. This works as the SIP proxy is run by the access operator. In RTCWeb the same could work if the calling site had a relationship with the access operator. I've heard that there is some work by some operators to offer Web APIs for 3rd party apps to do the bearer setup requests more ad hoc. Most of this may be outside the scope of RTCWeb but I think the document should have some explanation on how it works from the OS, browser, JS client, calling site, and mobile operator perspective. 

On the "transport" or "data path" level I don't think the browser needs to understand anything about QCIs. DSCP marking should be good enough. 

Anyone with more LTE/mobile clue that could comment on this? 

Markus

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 18 Sep 2012 06:27:36 -0700

On Sep 18, 2012 1:08 AM, <[email-masked]> wrote:
> I'm not even sure if the browser or even the OS can influence much the
QCI or bearer selection in LTE. I think the model is such that the
"network" sets up these special non-best-effort bearers, and gives the
endpoint the classifier rules related to them. The rules tell the endpoint
how to map outgoing packets to the bearers. Typically the rules are based
on source/destination IP and port, and the transport protocol. Someone may
be able to confirm, but I believe DSCP can be used too. But basically the
rules come from the network and the endpoint just follows them.
>
> So, somehow the browser or the JS app would first have to convince the
access network provider to setup the special bearer so that the right flows
get classified to it. In IMS the SIP proxy reads the SDP and tells some
network element what audio or video flows are being setup and what their
5-tuples are, so the network is being able to setup the bearers correctly
for them. The endpoint merely waits for this setup and acts accordingly.
This works as the SIP proxy is run by the access operator. In RTCWeb the
same could work if the calling site had a relationship with the access
operator. I've heard that there is some work by some operators to offer Web
APIs for 3rd party apps to do the bearer setup requests more ad hoc. Most
of this may be outside the scope of RTCWeb but I think the document should
have some explanation on how it works from the OS, browser, JS client,
calling site, and mobile operator perspective.
>
> On the "transport" or "data path" level I don't think the browser needs
to understand anything about QCIs. DSCP marking should be good enough.
> Anyone with more LTE/mobile clue that could comment on this?

Your understanding is similar to mine.

Generally speaking, qos in 3gpp networks is network initiated and
controlled by a PCRF. The UEs are generally not trusted, as they may abuse
qos.

I am told that qos is an important differentiator for the operator run
services and consequently will not be generally available to 3rd party apps
such as webrtc.

I am generally sceptical about qos on the internets, and we may be getting
into a dangerous area if we start to assume networks will give anything
more than best effort to webrtc.

CB _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2012 15:09:12 +0300

Hi Cameron, Hi Markus, 

your responses raise an interesting question: while everyone liked the idea presented in draft-jennings-rtcweb-qos it may have pretty limited practical value. There is the annoying layer issues (that we encounter in other areas in the IETF as well) that crosses our way. For cellular systems where the QoS mechanisms would provide the most benefits it does not work. If it would work then the QoS procedure would be available at the link layer during bearer establishment. For WLANs, where there are the least problems, you could also use the link layer specific QoS mechanisms (if at all needed). Same for Wimax. 

On top of that there is the architectural issue (namely, how this is supposed to work e2e). Not talking about the architectural story does not make the problem go away.

Ciao
Hannes

On Sep 18, 2012, at 4:27 PM, Cameron Byrne wrote:

> Generally speaking, qos in 3gpp networks is network initiated and controlled by a PCRF. The UEs are generally not trusted, as they may abuse qos.
> 
> I am told that qos is an important differentiator for the operator run services and consequently will not be generally available to 3rd party apps such as webrtc.
> 
> I am generally sceptical about qos on the internets, and we may be getting into a dangerous area if we start to assume networks will give anything more than best effort to webrtc.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 23 Sep 2012 23:04:59 +0000

I don't think the DSCP stuff in the draft is trying to solve any end to end problems or even make any guarantees about QoS anywhere. But the draft does clearly state where this does sometimes help (like the local DSL uplink from my house) and points out it won't help for something like end to end. 

On the topic of the QCI on smart phones. I agree that untrusted 3rd party applications are probably not going to be able to request QoS on most carrier networks. However, some carriers are clearly looking at the idea that there could be carrier provided RTCWeb applications that have a trust relationship that allows them to get different treatment. I don't claim to be a LTE expert but luckily Dan is an architect at a major carrier with strong interest in LTE so I'm pretty sure he can get this straightened out.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 24 Sep 2012 04:29:15 +0000

Hi Cullen -

You may want to look into (3GPP TS 23.401 V11.3.0) which permits UE to request bearer resource modification.

Section 5.4.5

"The UE requested bearer resource modification procedure for an E-UTRAN is depicted in figure 5.4.5-1. The procedure allows the UE to request for a modification of bearer resources (e.g. allocation or release of resources) for one traffic flow aggregate with a specific QoS demand."

--Tiru.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings (fluffy)
> Sent: Monday, September 24, 2012 4:35 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [rtcweb] draft-jennings-rtcweb-qos: QCI "marking"?
> 
> 
> I don't think the DSCP stuff in the draft is trying to solve any end to end
> problems or even make any guarantees about QoS anywhere. But the draft does
> clearly state where this does sometimes help (like the local DSL uplink from
> my house) and points out it won't help for something like end to end.
> 
> On the topic of the QCI on smart phones. I agree that untrusted 3rd party
> applications are probably not going to be able to request QoS on most carrier
> networks. However, some carriers are clearly looking at the idea that there
> could be carrier provided RTCWeb applications that have a trust relationship
> that allows them to get different treatment. I don't claim to be a LTE expert
> but luckily Dan is an architect at a major carrier with strong interest in LTE
> so I'm pretty sure he can get this straightened out.
> 
> 
> 
> 
> > your responses raise an interesting question: while everyone liked the idea
> presented in draft-jennings-rtcweb-qos it may have pretty limited practical
> value. There is the annoying layer issues (that we encounter in other areas in
> the IETF as well) that crosses our way. For cellular systems where the QoS
> mechanisms would provide the most benefits it does not work. If it would work
> then the QoS procedure would be available at the link layer during bearer
> establishment. For WLANs, where there are the least problems, you could also
> use the link layer specific QoS mechanisms (if at all needed). Same for Wimax.
> >
> > On top of that there is the architectural issue (namely, how this is
> supposed to work e2e). Not talking about the architectural story does not make
> the problem go away.
> >
> > Ciao
> > Hannes
> >
> >>> I'm not even sure if the browser or even the OS can influence much the QCI
> or bearer selection in LTE. I think the model is such that the "network" sets
> up these special non-best-effort bearers, and gives the endpoint the
> classifier rules related to them. The rules tell the endpoint how to map
> outgoing packets to the bearers. Typically the rules are based on
> source/destination IP and port, and the transport protocol. Someone may be
> able to confirm, but I believe DSCP can be used too. But basically the rules
> come from the network and the endpoint just follows them.
> >>>
> network element what audio or video flows are being setup and what their 5-
> tuples are, so the network is being able to setup the bearers correctly for
> them. The endpoint merely waits for this setup and acts accordingly. This
> works as the SIP proxy is run by the access operator. In RTCWeb the same could
> work if the calling site had a relationship with the access operator. I've
> heard that there is some work by some operators to offer Web APIs for 3rd
> party apps to do the bearer setup requests more ad hoc. Most of this may be
> outside the scope of RTCWeb but I think the document should have some
> explanation on how it works from the OS, browser, JS client, calling site, and
> mobile operator perspective.
> >>>
> >>> On the "transport" or "data path" level I don't think the browser needs to
> understand anything about QCIs. DSCP marking should be good enough.
> >>>
> into a dangerous area if we start to assume networks will give anything more
> than best effort to webrtc.
> >>