Subject: [tsvwg] Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) description in ndata

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 18 Aug 2015 13:41:48 +0200

Hi Michael,

In the context of understanding the SCREAM multi stream scheduling solution
(rmcat) I tried to do

some reference checking to understand the exact algorithm envisaged for the
ndata 3.1.6.  Weighted Fair Queueing Scheduler (SCTP_SS_WFQ).

Here it looks as there is a circular reference in between

https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13

section 6.4:

   o  A priority, which is a 2 byte unsigned integer.  These priorities

      MUST be interpreted as weighted-fair-queuing scheduling priorities

      per the definition of the corresponding stream scheduler

      supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata
<https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#ref-I-D.ietf-tsvwg-sctp-ndata>].
For use

      in WebRTC, the values used SHOULD be one of 128 ("below normal"),

      256 ("normal"), 512 ("high") or 1024 ("extra high").

and

http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/

section 3.1.6/3.2.6

3.2.5.  Weighted Fair Queueing Scheduler (SCTP_SS_WFQ_INTER)

3.2.5.  Weighted Fair Queueing Scheduler (SCTP_SS_WFQ_INTER)

   This scheduler is similar to the one described in Section 3.1.6, but

   based on I-DATA chunks instead of user messages.  This scheduler is

   used for WebRTC Datachannels as specified in

   [I-D.ietf-rtcweb-data-channel].

3.1.6.  Weighted Fair Queueing Scheduler (SCTP_SS_WFQ)

   A weighted fair queueing scheduler between the streams is used.  The

   weight is configurable per outgoing SCTP stream.  This scheduler

   considers the lengths of the messages of each stream and schedules

   them in a certain way to use the bandwidth according to the given

    ^^^^^^^^^^^^^^^^^^^^^^

   weights.

But neither document explicit tells, e.g., by at least a reference, what _*the
certain way*_ of weighted-fair-queuing scheduling

is.  Is the intend for the exact algorithm to be left to implementation
with only the intend that over time the required weighted bandwidth
fairness be achieved ?

Is it up to implementations to handle, just examples:,  how to overshoot
the CWND, to make it grow, if this means that the weighted bandwidth is
breached.

Which stream go first in consummation of the CWND to begin with. How to
evaluate message bundling options vis-à-vis fair weights.   More…

Would it not be relevant to give a general references as well as possibly
some  implementation notes for how such a solution is/can be made or more
explicitly state

what would be left to the implementation with a hint to some of the
intricate aspects involved.  I assume that the FreeBSD SCTP implementation
would be great source of information

for this (?)

BR, Karen

---

From: Dave Taht <[email-masked]>
Date: Tue, 18 Aug 2015 14:37:46 +0200

On Tue, Aug 18, 2015 at 1:41 PM, Karen Elisabeth Egede Nielsen
<[email-masked]> wrote:
>       supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata].  For use
>
> But neither document explicit tells, e.g., by at least a reference, what
> _the certain way_ of weighted-fair-queuing scheduling
>
> is.  Is the intend for the exact algorithm to be left to implementation with
> only the intend that over time the required weighted bandwidth fairness be
> achieved ?

I imagine so. There are a multitude of interesting WFQ schedulers in
the literature and/or available as open source code. One of the best
is QFQ+, for example. Something somewhat related are the fq_codel
derived ones, like "cake".

I am not sure why the fixed weights are so chosen in the draft.

>
> Is it up to implementations to handle, just examples:,  how to overshoot the
> CWND, to make it grow, if this means that the weighted bandwidth is
> breached.
>

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast