Subject: [rtcweb] Call for adoption of QoS draft

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Sep 2012 08:27:33 -0700

Based on the feedback at the last working group meeting, the chairs
believe that there is general support for creating a document that
describes the QoS issues relating to RTCWEB.  We would like to call
for adoption of draft-jennings-rtcweb-qos-00 as the input draft.  Dan
Druta has agreed to serve as the WG document editor, should this
document move forward.

Please send comments to the list by  September 16, 2012

Ted and Magnus

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 07 Sep 2012 17:04:23 -0400

I am all for it, especially that with Dan's agreeing to edit it, the 
document will be in good hands!

Igor

On 9/7/2012 11:27 AM, Ted Hardie wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 07 Sep 2012 14:29:17 -0700

> for adoption of draft-jennings-rtcweb-qos-00 as the input draft.  Dan

I support the publication of this draft as a working group item with Dan 
Druta as the editor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Sep 2012 14:32:38 -0700

+1

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 8 Sep 2012 06:43:50 +0530

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Rescorla
Sent: Saturday, September 08, 2012 3:03 AM
To: Timothy B. Terriberry
Cc: [email-masked]
Subject: Re: [rtcweb] Call for adoption of QoS draft

+1

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 9 Sep 2012 05:27:37 -0700

+1

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Sep 2012 16:11:00 +0200

I support the adoption of this draft.

Comments separately.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Sep 2012 16:15:11 +0200

Since this draft is mercifully short, I did a quick review.

Notes:

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

- I find it good that these 3 mechanisms are the only ones considered in 
the draft. I'm making the leap of faith that we intend to state that an 
implementation MUST implement DSCP codepoint marking, SHOULD implement 
QCI and WiFI markings when attached to appropriate interfaces, and that 
no other mechanism is going to get a MUST or SHOULD recommendation from 
the WG. If I'm right, can we make that explicit?

- The restriction to 3 levels of priority seems to me like a reasonable 
simplification. Again, I want to make sure that this is an explicit and 
supported choice of the group.

                Harald

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2012 09:38:16 -0700

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.

I agree that this would be useful, if the draft really did make
implementation (and use) of those markings a "SHOULD".  See below.

> - I find it good that these 3 mechanisms are the only ones considered in the
> draft. I'm making the leap of faith that we intend to state that an
> implementation MUST implement DSCP codepoint marking, SHOULD implement QCI
> and WiFI markings when attached to appropriate interfaces, and that no other
> mechanism is going to get a MUST or SHOULD recommendation from the WG. If
> I'm right, can we make that explicit?

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.

> supported choice of the group.

Like Cullen, I don't see much room for a fourth priority.  Nor do I
see any particular advantage in having the fourth.  2 just doesn't
seem like enough though.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2012 09:50:57 -0700

I think that the work is valuable and useful.

However, I have concerns about how priorities are communicated to the browser.

I know that this introduces an interesting case of where the
artificial division of labour between rtcweb and WebRTC breaks down,
but the recent ruling in the W3C implies that this would require SDP
work (unless there is something that I missed).  That would then imply
that this (new) work doesn't fit the rtweb charter and should go to
MMUSIC.

Did I miss a detail?

--Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Sep 2012 09:54:40 -0700

> that this (new) work doesn't fit the rtweb charter and should go to

Why would this require SDP work?

I would assume that this would be a setting on the media stream/track.
or alternately, a hint.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2012 10:43:38 -0700

> I would assume that this would be a setting on the media stream/track.

You could, but that means that you have a more complicated API to use.
 You have to set priority locally, signal the chosen priority, set the
signalled priority, etc...  As a session characteristic, I assumed
that you would want to put it in the SDP.  Or is this something that
is extra specific to WebRTC such that you don't want to provide this
to other SDP users?

--Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Sep 2012 10:51:40 -0700

On Mon, Sep 10, 2012 at 10:43 AM, Martin Thomson
<[email-masked]> wrote:
> signalled priority, etc...

It's not clear to me that these values need to be the same on both
sides.

But if it *is* true that we want that, then of course it should be in SDP so
that the functionality is available to endpoints that don't have anything
to do with WebRTC.

-Ekr

---

From: James Polk <[email-masked]>
Date: Mon, 10 Sep 2012 16:12:58 -0500

At 12:51 PM 9/10/2012, Eric Rescorla wrote:
>to do with WebRTC.'

MMUSIC has a WG item that should provide this indication/hint, in a 
trafficclass label attribute. Browsers identifying a small set of 
labels from that effort should do the trick. See

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-02.txt

James

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Sep 2012 14:27:53 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Rescorla
> Sent: Monday, September 10, 2012 10:52 AM
> To: Martin Thomson
> Cc: [email-masked]

They don't need to be the same.  But, once a packet comes into a
network that needs a certain DSCP value to get certain quality
of service, the packet needs to be treated accordingly.  

For example, let's say Alice and Bob are on different networks.
Someone decided Alice's network needs DSCP of "1" for its high 
priority traffic, and someone else decided Bob's network needs 
DSCP of "2" for high priority traffic.  When Alice and Bob
have a real time phone call with each other, their outgoing
packets will receive QoS treatment, but the incoming packets
won't.  

Do the network managers that configured Alice and Bob's network
need to use the same DSCP configuration, or do we want to
solve this some other way?

-d

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2012 14:27:58 -0700

On 10 September 2012 14:12, James Polk <[email-masked]> wrote:
> trafficclass label attribute. Browsers identifying a small set of labels
> from that effort should do the trick. See
>

Thanks James, that looks like what is needed.  It's not exactly the
same thing as the priority draft, so I'm not sure how I'd map all the
way from priority (1-3) to traffic class labels to the DSCP markings
described in Cullen's draft.

It looks like some more definition work is needed.

---

From: James Polk <[email-masked]>
Date: Mon, 10 Sep 2012 19:16:25 -0500

>described in Cullen's draft.

I'm not sure only 3 priorities are needed, though I believe 3 will 
get used. The point of the trafficclass labels (TCL) is to add a 
level of abstraction to what the actual DSCPs need to be by allowing 
each domain that is aware of the type of traffic choose the 
appropriate DSCP for that type of traffic. After all, some bright 
spark might just come along and suggest that even though RTCweb uses 
the same 5-tuple for all traffic, they propose that the audio packets 
use a different DSCP than the video packets.

Further, someone might consider the type of AV conference they are in 
to determine which DSCP they are to use. Say the difference between a 
small window av call and an immersive telepresence room experience? 
Both types of calls have the exact same types of packets (audio and 
video, and maybe preservation sharing or whiteboarding).

Another is Dan's point in which Alice uses her highest priority 
marking (DSCP 1) when she contacts Bob, who uses his highest priority 
marking (DSCP 2) for the same call. Now, which DSCP is the highest 
priority marking, 1 or 2? Does it depend on the network/domain the 
packet is in?

The TCL draft explores that, and we already have customer feedback 
that's caused us to allow greater flexibility than we originally planned.

>It looks like some more definition work is needed.

perhaps, and I'm not at all opposed to comments to the TCL draft 
within MMUSIC to address whatever folks think is important.

James

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2012 17:32:40 -0700

On 10 September 2012 17:16, James Polk <[email-masked]> wrote:
> perhaps, and I'm not at all opposed to comments to the TCL draft within
> MMUSIC to address whatever folks think is important.

I don't think that this necessarily translates to TCL draft work.
More that it is becoming clear to me that the qos draft is both a)
new, and b) not in alignment with the TCL stuff.  I'd be happy to be
convinced otherwise, and I'm sure that it can be rectified.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 17 Sep 2012 22:16:14 +0000

On Sep 10, 2012, at 18:16 , James Polk wrote:

> I'm not sure only 3 priorities are needed, though I believe 3 will get used. The point of the trafficclass labels (TCL) is to add a level of abstraction to what the actual DSCPs need to be by allowing each domain that is aware of the type of traffic choose the appropriate DSCP for that type of traffic.

The problem with using TCL here is the browser has no idea how to find out the mapping from TCL to DSCP for the domain it is currently running in so it can't use TCL to set the DSCP on the media packets. Subha and I talked about this a bunch and can not see any way to make TCL work.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 17 Sep 2012 22:16:51 +0000

> determine the markings for the link?  We should endeavour to maintain

On some OS is it is possible to see them but ignoring that … think for a second  about what these marketing are meant to be used for -  they are more meant to be seen by the network not the browser at the far end so not sure this matters much if the some OS can't provide this information to the application

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 17 Sep 2012 22:19:28 +0000

On Sep 10, 2012, at 8:15 , Harald Alvestrand 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.

I think the draft needs all the correct pointers to the specs for this the QCI / WIFI stuff as well as pointers to the normative mapping tables defined by the appropriate SDOs for them. If the device is sending a packet on a network that supports QCI or Wifi marking, it can use them.  I'm not really sure what else to say. (Note that I don't think this could be a MUST use ).

> 
> - I find it good that these 3 mechanisms are the only ones considered in the draft. I'm making the leap of faith that we intend to state that an implementation MUST implement DSCP code point

I have not tracked this all down but have been told that it might not be possible for a browser to do this in some versions of the windows operating system so I suspect the DSCP would end up being SHOULD not a MUST   

> m unforotanly arking, SHOULD implement QCI and WiFI markings when attached to appropriate interfaces, and that no other mechanism is going to get a MUST or SHOULD recommendation from the WG. If I'm right, can we make that explicit?
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 17 Sep 2012 22:24:31 +0000

I'd suggest using hint for this.

And I think this is a topic for webrtc not this wg.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2012 15:52:49 -0700

> On some OS is it is possible to see them but ignoring that … think for a second  about what these marketing are meant to be used for -  they are more meant to be seen by the network not the browser…

I am not suggesting anything about reading the markings off packets.
Reading markings off is - as you say - close to useless.

I asked if it were possible to consider *not* specifying what link
layer markings are made for packets that are *sent*.  The suggestion
was that if DSCP markings were made, as suggested, the packets could
be marked on the way onto the link by the wireless driver using
whatever link-specific markings are appropriate.  That might lead to a
mapping from DSCP to QCI and WiFi markings, but not necessarily.  That
would be different to the straight-from-the-top application priority
to link-layer, as described in the draft.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2012 15:56:45 -0700

> I have not tracked this all down but have been told that it might not be possible for a browser to do this in some versions of the windows operating system so I suspect the DSCP would end up being…

As I understand it, setting DSCP can be disabled by group policy.
This is an explicit request from certain network operators, usually
enterprises who have the ability to set such policies.

As a matter of interest, some of the same networks do still perform
traffic prioritization for audio and video traffic.  They do it based
on port ranges.  You could infer some requirements from that.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Sep 2012 16:45:47 -0700

> on port ranges.  You could infer some requirements from that.
<choosing to not go with the witty repartee>

The normal case for client-server communication is that the server has 
fixed port numbers, and the client just uses the port number the OS 
gives it; the network's priority setting is then done on the server port 
number range.

There are "fun" issues with trying to set port numbers on clients, 
including how to ACL them (I don't know of an OS that can do that), and 
the problem of port number collision.
For client-client communication, I think DSCP has a better chance of 
succeeding (not a big chance. Just a better chance).

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 20 Sep 2012 08:17:37 +0000

Hi,

agree that the QCI stuff is probably not useful to discuss.

The DSCP content is almost fully redundant with what's in RFC4594 (which is in the references but not cited). And RFC4594 has a much better discussion on what DiffServ is and isn't.

For WLAN, 802.11e is what you want to point to, I guess.

So this doc - if it's even needed - could be MUCH shorter, by basically just saying "read RFC4594 and map RTCweb flows into the classes defined there like this" and do the equivalent for 802.11e.

Lars

---

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

> The DSCP content is almost fully redundant with what's in RFC4594 (which is in the references but not cited). And RFC4594 has a much better discussion on what DiffServ is and isn't.

So this is trying to work within the bounds of 4594 (and clearly needs to reference that) but I think this narrows things down a bit more that 4594 might or at least tries to clarify things a bit . 

For example 4594 says use "Multimedia Conferencing service class is best suited … video conferencing service"

It also says "Real-Time Interactive is intended for … and video conferencing applications"

It also suggest there are times the right thing for video might be "Multimedia Streaming service class"

As a result we see some major vendors shipping video phone like devices using CSx class while others are using AFx set. 

So this may be 100% redundant with 4594 depending on your point of view - or it might not be redundant -  but we need one clear unambiguous thing about what needs to happen. If it can be reduced to two sentences, I'm all for that. 

> So this doc - if it's even needed - could be MUCH shorter, by basically just saying "read RFC4594 and map RTCweb flows into the classes defined there like this" and do the equivalent for 802.11e.

It also forms the requirement for the three priority levels at a JS layer and pointed out we don't want the JS setting if a stream is says audio or video.

> 
> Lars_______________________________________________
> rtcweb mailing list
> [email-masked]