Subject: [rtcweb] Some language on "prioritization"

From: Harald Alvestrand <[email-masked]>
Date: Mon, 31 Mar 2014 19:08:48 +0200

I see that I have promised to sugggest language for -transport- about
prioritization.
Here's an attempt. References and so on to be filled in later.

Comments welcome - this is a first stab!

--------------------------------------------
The RTCWEB prioritization model is that the application tells the RTCWEB
implementation about the priority of media and data flows through an API.

The priority associated with a media or data flow is classified as
"normal", "below normal", "high" or "very high". There are only four
priority levels at the API.

The RTCWEB implementation is responsible for mapping these to protocol
mechanics at the protocol interfaces, and to behave appropriately when
choosing what packets to send when.

[draft-dhesikan] specifies the mapping of the four levels of priority,
combined with the media type, to DSCP markings. This marking SHOULD be
done; the implementation MAY turn off use of DSCP markings if it detects
symptoms of unexpected behaviour like priority inversion or blocking of
packets with certain DSCP markings. The detection of these conditions is
implementation dependent. (Question: Does there need to be an API knob
to turn off DSCP markings?)

When an RTCWEB implementation has packets to send on multiple streams
that are congestion-controlled under the same congestion controller, the
RTCWEB implementation SHOULD serve the streams in a weighted round-robin
fashion, with each level of priority being given twice the transmission
capacity of the level below; thus, when congestion occurs, a "very high"
priority flow will have the ability to send 8 times as much data as a
"below normal" flow if both have data to send. This prioritization is
independent of the media type, but will lead to packet loss due to full
send buffers occuring first on the highest volume flows at any given
priority level. The details of which packet to send first are
implementation defined.

-- TODO: Specify a relative priority scheme that makes sense with SCTP,
with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies]
specifies a priority policy, but it's about discarding packets, not
deciding which packets to send first, and it also makes it impossible to
specify time-bounded retransmission. --

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Mar 2014 10:38:08 -0700

> specify time-bounded retransmission. --

Why would SCTP need special treatment?  I can understand if there are
particular time-sensitive control messages that need to be given
higher priority, but this is all time-sensitive.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 31 Mar 2014 19:42:59 +0200

> higher priority, but this is all time-sensitive.
A single transport connection (in this case an SCTP association) can
only use a single DSCP. So it would be OK to use the same priority for
all data channels, but things get complicated when when some data channels
would have different priorities requiring different DSCP markings.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 31 Mar 2014 19:48:08 +0200

> would have different priorities requiring different DSCP markings.

The SCTP protocol machine will, at some given moment in time, have
packets in its send buffers that belong to multiple data channels. Only
one of them can go on the wire first.

Which packet does it choose to send first, and why?

That's the question I'm looking for an answer to.

If the answer has an RFC number, chapter and section, I'd be very happy.
If it doesn't - perhaps we have to invent one.
Or say that it's "implementation dependent".

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 31 Mar 2014 17:49:45 +0000

And if SCTP and RTP have packets to send, which goes first, why, and under what circumstances?

Matthew Kaufman

(Sent from my iPhone)

> On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" <[email-masked]> wrote:
>