Subject: [rtcweb] Text for data-channel priority

From: Randell Jesup <[email-masked]>
Date: Tue, 20 May 2014 18:59:06 -0400

6.4 Channel Definition

Old text:
*... Each data channel also has a priority. These priorities MUST NOT be 
strict priorities. *

New text:
*... Each data channel also has a priority, which is an unsigned 2 byte 
value.  These priorities MUST be interpreted as weighted-fair-queuing 
scheduling priorities per the definition in [I-D.ietf-tsvwg-sctp-ndata].*

Note that the next revision of ndata (-01) will add the 
weighted-fair-queuing option to section 4.1.2.  The W3 working group has 
the job of mapping JS-level priorities to the values to be used here 
(such as 1, 2 ,4, 8  or 100, 200, 400, 800).

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 May 2014 08:04:03 +0200

On 21 May 2014, at 00:59, Randell Jesup <[email-masked]> wrote:

> 6.4 Channel Definition
> 
> Old text:
> ... Each data channel also has a priority. These priorities MUST NOT be strict priorities. 
> 
> 
> New text:
> ... Each data channel also has a priority, which is an unsigned 2 byte value.  These priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per the definition in  [I-D.ietf-tsvwg-sctp-ndata].
> 
> 
> Note that the next revision of ndata (-01) will add the weighted-fair-queuing option to section 4.1.2.  The W3 working group has the job of mapping JS-level priorities to the values to be used here (such as 1, 2 ,4, 8  or 100, 200, 400, 800).
Is it the W3C group or the IETF WG? I personally don't care. My initial suggestion was that it
is done the IETF WG... That would require to add a simple table to the above text.

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Wed, 21 May 2014 10:21:39 -0400

On 5/20/2014 6:59 PM, Randell Jesup wrote:
>
>
>       6.4 Channel Definition
>
> Old text:
> *... Each data channel also has a priority. These priorities MUST NOT 
> be strict priorities. *
>
>
> New text:
> *... Each data channel also has a priority, which is an unsigned 2 
> byte value.  These priorities MUST be interpreted as 
> weighted-fair-queuing scheduling priorities per the definition in  
> [I-D.ietf-tsvwg-sctp-ndata].*
>
>
> weighted-fair-queuing option to section 4.1.2.  The W3 working group 
> has the job of mapping JS-level priorities to the values to be used 
> here (such as 1, 2 ,4, 8  or 100, 200, 400, 800).

Per discussion in the room & jabber, I'll revise the data-channel to 
include the above (though 32-bit, since the ndata priority range 
32-bit), and also rev data-protocol as follows:

Old text:
*Priority: 2 bytes (**unsigned **integer): **
**The priority of the channel as described in 
[I-D.ietf-rtcweb-data-channel]. The higher the number, the lower the 
priority.

*New text:
*Priority: 2 bytes (**unsigned **integer): **
**The priority of the channel as described in 
[I-D.ietf-rtcweb-data-channel]. The higher the number, the lower the 
priority.  For use in WebRTC, the values used should be one of 128 
("extra high"), 256 ("high"), 512 ("normal") or 1024 ("below normal").*

Note that the size of priority here is for the DCEP Open message, so it 
doesn't have to be 32-bit even if data-channel allows that range.  (And 
in fact we're using far less than the entire available range currently 
for webrtc, per the text above.)

I'll respin both drafts.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 May 2014 08:52:16 -0700

On 21 May 2014 07:21, Randell Jesup <[email-masked]> wrote:
> The priority of the channel as described in [I-D.ietf-rtcweb-data-channel].
> The higher the number, the lower the priority.  For use in WebRTC, the
> values used should be one of 128 ("extra high"), 256 ("high"), 512
> ("normal") or 1024 ("below normal").

Are these weights back to front?  Wouldn't that have high getting half
the bits allocated to normal?

BTW, I should explain my numbers.  For partitioning a logarithmic
space, the middle of the range is sqrt(max), which in this case is the
256 value.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 May 2014 17:53:04 +0200

On 21 May 2014, at 16:21, Randell Jesup <[email-masked]> wrote:

> Per discussion in the room & jabber, I'll revise the data-channel to include the above (though 32-bit, since the ndata priority range 32-bit), and also rev data-protocol as follows:
> 
> Old text:
> Priority: 2 bytes (unsigned integer):  
> The priority of the channel as described in [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower the priority.
> 
> New text:
> Priority: 2 bytes (unsigned integer):  
> The priority of the channel as described in [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower the priority.  For use in WebRTC, the values used should be one of 128 ("extra high"), 256 ("high"), 512 ("normal") or 1024 ("below normal").
To keep things simple: Can we just use weights? So something like:

128    "below normal"
256    "normal"
512    "high"
1024   "extra high"

Best regards
Michael
> 
> Note that the size of priority here is for the DCEP Open message, so it doesn't have to be 32-bit even if data-channel allows that range.  (And in fact we're using far less than the entire available range currently for webrtc, per the text above.)
> 
> I'll respin both drafts.
> 
> -- 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Wed, 21 May 2014 11:57:04 -0400

> To keep things simple: Can we just use weights? So something like:

Good by me.  Wasn't obvious given it's not in ndata yet which end was up.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 May 2014 18:00:13 +0200

> Good by me.  Wasn't obvious given it's not in ndata yet which end was up.
Sure... This allows just to provide the weights in the API...

Best regards
Michael