Subject: Re: [rtcweb] Some language on "prioritization"

From: "Karl Stahl" <[email-masked]>
Date: Thu, 3 Apr 2014 18:30:08 +0200

The questions raised here don't have simple "local or endpoint answers".
There are overall and basic things to be made clear first. 
Combining P2P file transfer over the rtcweb data channels with 
prioritized traffic chunks, brings further complications to the 
prioritization/QoS issue. This cannot be handled/done by endpoint or 
applications without considering the transport network (The congestion 
to handle by prioritization is in the network - NOT in the endpoints)! 

There are below (A), (B) and (C) - to get us back to normal - then there 
is (D) to improve - to allow the network level to give us the 
prioritization required for WebRTC critical traffic 
(real-time and data chunks). Without (D) - an interface to network QoS 
equipment - the network does not even know what to prioritize.

I am afraid that this will be considered "back to the drawing board" 
rather than "some language" but I cannot see the way forward if not 
considered. 

Has the SCTP data channel been constructed with hopes of 
prioritization/quality functionality that simply are not there 
(cannot be there)? (I have browsed the (complex) SCTP spec and some 
rtcweb drafts to get an understanding of the prioritization/QoS thoughts 
and means in this rtcweb context and the intended usage. Is there an 
overall design/thought somewhere that I missed/am unaware of?)

File transfer - getting a larger amount of data through between endpoints 
as quickly as possible - CANNOT be prioritized over IP networks! For file 
transfer we normally use TCP, meaning we fill the pipe, until THE 
ENDPOINTS see packet drop and regulate down their traffic flow. File 
transfer over IP networks works this way and cannot be improved upon 
("Internet would stop" if we prioritized such traffic! The available 
bandwidth at congestion points are shared between everyone's TCP-flows 
hitting such congestion points in the network.) File transfer's nature is 
to have "infinite bandwidth demand" - the mechanism to handle this is to 
allow file transfer to "take the rest of the bandwidth" after prioritized 
media and chunks have taken their needed share. 

The improvement to make - prioritization of media traffic and data chunks 
- is to allow level 3 QoS methods - not only relying on the level 4 TCP 
backing off process. Without level 3 QoS (diffserve/DSCP, reservation or 
separate pipes) media and data chunks packets are also lost in the 
level 4 TCP backing off process (=today's situation over best effort 
Internet). That is where the prioritization/QoS measures that we need for 
rtcweb have to be.

SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve things.
It can destroy though if wrongly/badly implemented or used!

>From the SCTP RFC4960: 7.  Congestion Control 
   ...adequate resources will  be allocated to SCTP traffic 
   to ensure prompt delivery of time-critical data ... unlikely, 
   during normal operations, that transmissions encounter severe 
   congestion conditions.  

   However, SCTP must operate under adverse operational
   conditions, which can develop upon partial network failures 
   or unexpected traffic surges.  In such situations, SCTP must 
   follow correct congestion control steps to recover from 
   congestion quickly in order to get data delivered as soon as 
   possible.  

   ... SCTP congestion control is always applied to the entire 
   association, and not to individual streams.

Doing file transfer with the data channel will use SCTP in the "adverse 
operational conditions, which can develop upon partial network failures 
or unexpected traffic surges"-mode! Has that been considered when 
constructing the data channel? Hope so...

Assuming SCTP is implemented correctly and as good as TCP for file 
transfer (even though file transfer = filling the pipe mode is an 
"adverse condition..." for SCTP). Then we must specify:

(A) Rtcweb file transfer MUST NOT use the same data channel as data 
chunks expected to have prioritized delivery (otherwise, as per 
above, SCTP will regulate the "the entire association" to share the 
available bandwidth at the congestion point - self-destroying the 
expected prioritized delivery of data chunks in the same channel).

(B) Each rtcweb file transfer MUST use its own data channel (if 
combined they risk being regulated randomly/unfairly by SCTP itself 
and all files will have just have one single TCP-like flow at the 
network congestion point when sharing the available bandwidth with 
everyone else's flows at that congestion point - That would be 
"negative priority" compared to what we are used to in a browser.).

FURTHER, to allow the underlying network the ability to handle the 
real-time and data chunks as least as good as "before rtcweb" 
(Unfortunately this will make NAT-firewall less good - not sending 
everything P2P in a single bundle/flow - I don't like it either... 
Sorry...):

(C) File transfer using the data channel MUST NOT be bundled with 
media and data chunk traffic in the same flow - file transfer must 
use a separate socket creating another flow/5-tuple over the network. 
(In reservation type of networks (e.g. mobile OTT, cable), file 
transfer - having no bandwidth limitation - would otherwise overflow 
the reserved bandwidth for media and chunck traffic - destroying 
prioritized delivery of media and chunck traffic over that flow.) 
Such file transfer data channels MUST NOT be prioritized by the 
underlying network (applies to all IP network types, network 
prioritization of file transfer will STOP traffic between endpoints 
- Endpoint's TCP-like regulation has to function!). Several file 
transfers could share such a separate flow (without specifying in 
SDP I guess) but the underlying network must be able to separate 
such flows (not to be prioritized) from media and chunk flows. 

In the API, such file transfer data channel could be mapped to the 
"below normal" classification (but would it not be better with a 
"file transfer channel" API instead?). (And notice that without (D) 
below, the network is not informed how to separate a file transfer 
data channel flow from a prioritized data channel flow.)

Having (A), (B) and (C) in place we are BACK TO THE CURRENT 
Internet prioritization/QoS level - before the rtcweb p2p data 
channel file transfer was introduced...

Now remains the prioritization improvement required for quality 
hungry rtcweb! Both for the real-time media and the data chuncks.

(D) The underlying transport network needs to be informed about 
the traffic requirements. 

- In RTP media this traffic info could be inserted by the rtcweb 
browser in the RTP header extension [1] depending on codec usage 
etc. The API classification could be mapped to the 
"Prioritize X(2 bits)" suggested in [1] below.

- for the data channel, the traffic info could be inserted as 
suggested in previous email ([2] below) 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html  

Note that the required bandwidth (only known by the 
browser/application) has to be passed to reservation types of 
network. Requested prioritization from the API or DSCP bits are 
not sufficient. The browser knows the bandwidth requirements for 
codecs, but for data chunks, the application has the knowledge. 
In lack of a bandwidth parameter in the data channel API, a simple 
convention - e.g. reserve 200 kbps for data chunks could serve as 
a compromise (or 4 bandwidths mapped to the API prioritize 
classifications...). A modified API with the bandwidth requirement 
spelled out would of course be better for the chuck data channel. 
For a file transfer data channel - prioritization classification 
does not even apply.  

Having prioritization over the network cleared, the application 
should use that transport properly - having media and data chunks 
transported with prioritization (as produced/inserted), NOT queuing 
them up, rearranged by protocols or applications and NOT involving 
file transfer (that has to be unprioritized). 

Using DSCP bits if available through the OS in some situations does 
not help either, as already pointed out in the transport document. 
For (D) above, DSCP bits could in a few situations function locally, 
but not end-to-end, so of no use generally. 
 
/Karl

[1] Traffic type information to encode (recreating the 
idea/intention of the RTP payload type (PT) header that is not 
available for the network level anymore, by instead having the 
browser filling the RTP header extension with relevant traffic 
info that all IP network types can use.), as suggested already 
October 22. Two parameters to encode 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 

A) The maximum bandwidth requirement: Two bytes could contain 
everything from some bps for real-time text to Gbps for future 3D 
supersize telepresence on a logarithmic scale.
 
B) The quality characteristics for the stream, with the highest 
bit set to 1, we could allocate a bit each for quality type e.g: 
Best Effort, Audio, Video, Supplemental Video, Gaming, Data, 
Delay Insensitive (e.g. video streaming), Minimum Delay, 
Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits), 
that could be combined as required to describe the stream.

And with the highest bit set to 0, there could instead be a number 
for special usage that does not fit the general description of 
the individual bits.

Without this information, how could e.g. a reservation type 
network (e.g. mobile OTT and cable) reserve the bandwidth 
required for incoming rtcweb media or data chunks from a diffserve 
network (carrying no bandwidth requirement)? 

[2] A new DTLS ContentType (e.g. 24 instead of current 23) for the 
rtcweb data channel, where the content would be the unencrypted 
traffic info (preferable the same as in the RTP header extension) 
followed by the SCTP data as it is today (where it today comes 
directly in the DTLS as the only content).:

TODAY:
Content Type: 23 (1 byte) content type 23 means “application data”
DTLS version:  0xfeff (2 byte)
Epoch: 0001 (2 byte)
Sequence number (e.g. 00 00 00 00 00 01) 6 byte
Length (e.g. 01 c0) 2 byte
Encrypted application data: ...... = the SCTP
 
SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS: 
Content Type: 24 (1 byte) content type 24 meaning “application data preceded
by traffic info”
DTLS version:  0xfeff (2 byte)
Epoch: 0001 (2 byte)
Sequence number (e.g. 00 00 00 00 00 01) 6 byte
Length (e.g. 01 c0) 2 byte: length of the encrypted application data after
the new header extension
TRAFFIC INFO, Same as suggested for the RTP Header extension: 
Encrypted application data: ...... ...... = the SCTP unchanged

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Matthew Kaufman (SKYPE)
Skickat: den 31 mars 2014 19:50
Till: Harald Alvestrand
Kopia: [email-masked]
Ämne: Re: [rtcweb] Some language on "prioritization"

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:
> 
>> On 03/31/2014 07:42 PM, Michael Tuexen wrote:
>>> On 31 Mar 2014, at 19:38, Martin Thomson <[email-masked]>
wrote:
>>> 
>>>> On 31 March 2014 10:08, Harald Alvestrand <[email-masked]> wrote:
>>>> -- 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. --
>>> 
>>> 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.
>> 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.
> 
> 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".
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 3 Apr 2014 21:11:49 +0200

> overall design/thought somewhere that I missed/am unaware of?)
The basis idea is to use a stream scheduler to handle streams different.
Some data channels can get a higher bandwidth than others. Since the
priority stuff is still in flux in W3C, it hasn't been nailed down in
the SCTP spec. I guess, the place will be in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00
This document is not finalized yet.
> expected prioritized delivery of data chunks in the same channel).
If you use a data channel for file transfer, why would you put anything
else there? If has no sequencing constraints with the file transfer.
> (B) Each rtcweb file transfer MUST use its own data channel (if 
Yepp. I would do that anyway...

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 04 Apr 2014 10:51:43 +0200

I assume this is the scheduler envisioned in -ndata:

      SCTP_SS_PRIORITY:  Scheduling with different priorities is used.
         Streams having a higher priority will be scheduled first and
         when multiple streams have the same priority, the default
         scheduling should be used for them.  The priority can be
         assigned with the sctp_stream_value struct.  The higher the
         assigned value, the lower the priority, that is the default
         value 0 is the highest priority and therefore the default
         scheduling will be used if no priorities have been assigned.

This sounds like a "strict" scheduler, in that higher priority queues
will starve out lower priority ones completely. I remember having the
discussion at an IETF meeting about whether we wanted a "strict"
scheduler or a "weighted round robin" scheduler for this, but I wouldn't
trust my memory with what the conclusion was.

Was the conclusion that we should do "strict" scheduling? If so, it may
be best to make that consistent across the board - I had written in a
"weighted" scheduler for media into the prioritization text that I
started this thread with, but I think there's value to consistency.

(Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER
in another place. Is there a subtlety here I'm not seeing?)

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Apr 2014 12:48:32 +0200

On 04 Apr 2014, at 10:51, Harald Alvestrand <[email-masked]> wrote:

> This sounds like a "strict" scheduler, in that higher priority queues will starve out lower priority ones completely. I remember having the discussion at an IETF meeting about whether we wanted a "strict" scheduler or a "weighted round robin" scheduler for this, but I wouldn't trust my memory with what the conclusion was.
It is.
> 
> Was the conclusion that we should do "strict" scheduling? If so, it may be best to make that consistent across the board - I had written in a "weighted" scheduler for media into the prioritization text that I started this thread with, but I think there's value to consistency.
No, in an IETF WG meeting we discussed this a while ago and the result was a non-strict
priority, weighted fair queueing. This scheduling discipline in not there yet.
> 
> (Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER in another place. Is there a subtlety here I'm not seeing?)
Yes, there is a difference. It is about interleaving. You can use SS_PRIO
with or without NDATA, SS_PRIO_INTER only with NDATA.
This document still needs some work... Even the constant names might change...

Best regards
Michael

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Fri, 4 Apr 2014 11:55:50 +0000

Do we really want the default (lazy coder) behavior to be highest priority in this case?

I assume the priority is browser-wide and so this could disrupt other app's streams?

J

On Apr 4, 2014, at 4:52 AM, "Harald Alvestrand" <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Apr 2014 14:49:39 +0200

> Do we really want the default (lazy coder) behavior to be highest priority in this case?
Harald is referring to the SCTP socket API description. This won't be exposed
to the JS user. What will be exposed there needs to be defined by W3C and
will be mapped to the API of the SCTP implementation.
> I assume the priority is browser-wide and so this could disrupt other app's streams?
The priories described below are only relevant for the streams of an SCTP
association. It is just a scheduler which deals with the streams of an SCTP
association.

Best regards
Michael
> 
> J
>> 
> 
> On Apr 4, 2014, at 4:52 AM, "Harald Alvestrand" <[email-masked]> wrote:
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Apr 2014 15:13:41 +0200

Just checking... since there's been no comment to the main body of the 
text here (it's all been on the SCTP aspect), is it OK to include the 
text in my next version of the -transport draft?

(I'm not responding to Karl's comments - it's at a completely different 
level of complexity.)

        Harald

On 03/31/2014 07:08 PM, Harald Alvestrand wrote:
> 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]
> deciding which packets to send first, and it also makes it impossible to
> specify time-bounded retransmission. --
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2014 11:02:38 -0400

> "negative priority" compared to what we are used to in a browser.).

I presume you mean each *concurrent* file transfer must use its own 
channel. Right? Reusing the same channel to transfer a series of files 
should be fine.

	Thanks,
	Paul

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 10 Apr 2014 17:34:32 +0200

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Paul Kyzivat
Skickat: den 10 april 2014 17:03
Till: [email-masked]
Ämne: Re: [rtcweb] Some language on "prioritization"

> "negative priority" compared to what we are used to in a browser.).

I presume you mean each *concurrent* file transfer must use its own channel.
Right? Reusing the same channel to transfer a series of files should be
fine.

	Thanks,
	Paul
Yes, That is right. /Karl
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 11 Apr 2014 09:01:40 +0200

On 10 Apr 2014, at 15:13, Harald Alvestrand <[email-masked]> wrote:

> Just checking... since there's been no comment to the main body of the text here (it's all been on the SCTP aspect), is it OK to include the text in my next version of the -transport draft?
> 
> (I'm not responding to Karl's comments - it's at a completely different level of complexity.)
> 
>       Harald
> 
The text reads good to me.
>> specify time-bounded retransmission. --
No sure about this TODO. The priorities in draft-ietf-tsvwg-sctp-prpolicies are
not related to the kind of priorities you describe above. Your above apply
also to reliable channels.

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Apr 2014 09:23:25 +0200

> also to reliable channels.

We've already settled that none of the current policies in -ndata do
what the WG wants (weighted round robin), so I think it's correct to
leave this as a TODO, and punt this to TSVWG.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 21 Apr 2014 14:13:12 +0200

1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA
CHANNEL

Simon,

I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a 
webrtc file transfer channel (separate from the rtcweb data channel) 
to be created, using TLS file transfer P2P? ICE/STUN/TURN would set 
it up, NOT BUNDLED with chunk data and RTP media.

Freeing the current rtcweb data channel from file transfer would remedy 
the self destruction of prioritization/QoS for data chunks and RTP media 
as explained in (A), (B) and (C) below.

I also think it would be much better for a web programmer to have a 
separate p2p file transfer channel (that is not and cannot be prioritized) 
than pouring files into the data channel.

2) MARKING PRIORITY DATA AND MEDIA FOR NETWORK LEVEL PRIORITIZATION/QoS

Pål, Harald, Magnus, Collins, Tiru, Dan,

We have previously discussed how to convey traffic info (bandwidth 
requirement, and traffic type/prio) from the browser/application to 
the network layer to prioritize or take other QoS measure by some 
network element.

I have been pushing for inserting such traffic info into every RTP 
media packet in the RTP header extension, see [1] below.

After looking how to mark data channel priority data chunks similarly, 
I suggested [2] below, i.e. a new DTLS ContentType for the rtcweb 
data channel, where the content would be the unencrypted traffic 
info (preferable the same as in the RTP header extension) followed by 
the SCTP data. 

Are there other ways? - Maybe more similar, consistent and/or better?

We need the traffic info (contrary to e.g. DSCP bits) to be unchanged 
end-to-end and available in both STUN and TURN flows for network 
elements to see and act upon (e.g. to set DSCP bits or reserve 
bandwidth or otherwise regulate) for various network types. The 
traffic info must also be possible for network elements to find.

No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot 
that DTLS also hold the traffic info, just as for the data chunks 
- instead of putting the traffic info into the RTP header extension? 
NO, here the DTLS is only in the key exchange packets - not in every 
packet so that would NOT work, unfortunately.

A way c?) Why not send data chunks in SRTP (instead of SCTP) and 
reuse the RTP header extension for the traffic info for the network 
layer. (File transfer is done in 1) above - not here!)

What other things from SCTP do we actually want? (Not everything 
from that complex protocol for carrying telephony signaling can be 
of interest for webrtc.) 

- Priority (local): The browser could have a prioritizing mechanism 
including both media and data chunks before putting it in the UDP 
socket (simpler than SCTP).

- Reliable data: A small transaction layer with retransmission of 
reliable data chunks could be implemented by the browser (simpler 
than SCTP).

So with this way c, SCTP would go away totally and only the RTP 
header extension would be used for traffic info to the network layer.

Are there more ways? We need this traffic info to allow WebRTC with 
acceptable QoS over all network types (especially mobile Internet/OTT 
LTE and Cable Networks that are of reservation type).

Below are also a few comments to other feedback.
 
/Karl

On 10 Apr 2014, at 17:35, Paul Kyzivat [[email-masked]] wrote:
I presume you mean each *concurrent* file transfer must use its own channel.
Right? Reusing the same channel to transfer a series of files should be
fine.

	Thanks,
	Paul
[Karl] Yes, That is right. /Karl

On 10 Apr 2014, at 15:14, Harald Alvestrand [[email-masked]] wrote:
Just checking... since there's been no comment to the main body of the text
here (it's all been on the SCTP aspect), is it OK to include the text in my
next version of the -transport draft?

[Karl] Yes, it is but needs to be addressed. I think file transfer 
just be taken out of the data channel, and a file transfer channel 
(on a separate flow, as suggested above) be defined for Web 
programmers to use. That would remedy (A), (B) and (C) below (p2p 
file transfer not destroying priority for data chunks and media). 
The file transfer channel would not/cannot be prioritized. 

On 03 Apr 2014, at 21:12, Michael Tuexen
[[email-masked]]wrote:
>Is there an
The basis idea is to use a stream scheduler to handle streams different.
Some data channels can get a higher bandwidth than others. Since the
priority stuff is still in flux in W3C, it hasn't been nailed down in the
SCTP spec. I guess, the place will be in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00
This document is not finalized yet.
[Karl] There are severe limitations for doing prioritization in a 
protocol (SCTP or other) executed in the endpoints. In most cases 
there are no packets in the endpoint to put first among queued up 
traffic, because the queue is somewhere else between the endpoints. 
Just consider the most common case where the endpoints are connected 
with a fast Ethernet. The data has then already left the endpoint and 
is queued up at some congestion point in the network where the SCTP 
protocol cannot rearrange the queue. First when that unreachable 
queue is full, there is something in the endpoint to act upon...

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Karl Stahl
Skickat: den 3 april 2014 18:30
Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus Westerlund'
Kopia: [email-masked]
Ämne: Re: [rtcweb] Some language on "prioritization"

The questions raised here don't have simple "local or endpoint 
answers". There are overall and basic things to be made clear first. 
Combining P2P file transfer over the rtcweb data channels with 
prioritized traffic chunks, brings further complications to the 
prioritization/QoS issue. This cannot be handled/done by endpoint 
or applications without considering the transport network (The 
congestion to handle by prioritization is in the network - NOT in 
the endpoints)! 

There are below (A), (B) and (C) - to get us back to normal - 
then there is (D) to improve - to allow the network level to 
give us the prioritization required for WebRTC critical traffic 
(real-time and data chunks). Without (D) - an interface to 
network QoS equipment - the network does not even know what to 
prioritize.

Has the SCTP data channel been constructed with hopes of 
prioritization/quality functionality that simply are not there 
(cannot be there)? (I have browsed the (complex) SCTP spec and 
some rtcweb drafts to get an understanding of the 
prioritization/QoS thoughts and means in this rtcweb context 
and the intended usage. Is there an overall design/thought 
somewhere that I missed/am unaware of?)

File transfer - getting a larger amount of data through between 
endpoints as quickly as possible - CANNOT be prioritized over 
IP networks! For file transfer we normally use TCP, meaning we 
fill the pipe, until THE ENDPOINTS see packet drop and regulate 
down their traffic flow. File transfer over IP networks works 
this way and cannot be improved upon ("Internet would stop" if 
we prioritized such traffic! The available bandwidth at congestion 
points are shared between everyone's TCP-flows hitting such 
congestion points in the network.) File transfer's nature is 
to have "infinite bandwidth demand" - the mechanism to handle 
this is to allow file transfer to "take the rest of the bandwidth" 
after prioritized media and chunks have taken their needed share. 

The improvement to make - prioritization of media traffic and 
data chunks - is to allow level 3 QoS methods - not only relying 
on the level 4 TCP backing off process. Without level 3 QoS 
(diffserve/DSCP, reservation or separate pipes) media and data 
chunks packets are also lost in the level 4 TCP backing off 
process (=today's situation over best effort Internet). That is 
where the prioritization/QoS measures that we need for rtcweb 
have to be.

SCTP in itself (instead of TLS/TCP) does not/cannot/will not 
improve things. It can destroy though if wrongly/badly 
implemented or used!

Doing file transfer with the data channel will use SCTP in the 
"adverse operational conditions, which can develop upon partial 
network failures or unexpected traffic surges"-mode! Has that been 
considered when constructing the data channel? Hope so...

Assuming SCTP is implemented correctly and as good as TCP for 
file transfer (even though file transfer = filling the pipe 
mode is an "adverse condition..." for SCTP). Then we must specify:

(A) Rtcweb file transfer MUST NOT use the same data channel as 
data chunks expected to have prioritized delivery (otherwise, 
as per above, SCTP will regulate the "the entire association" 
to share the available bandwidth at the congestion point - 
self-destroying the expected prioritized delivery of data chunks 
in the same channel).

(B) Each rtcweb file transfer MUST use its own data channel (if 
combined they risk being regulated randomly/unfairly by SCTP 
itself and all files will have just have one single TCP-like 
flow at the network congestion point when sharing the available 
bandwidth with everyone else's flows at that congestion point 
- That would be "negative priority" compared to what we are used 
to in a browser.).

FURTHER, to allow the underlying network the ability to handle 
the real-time and data chunks as least as good as "before rtcweb" 
(Unfortunately this will make NAT-firewall less good - not sending 
everything P2P in a single bundle/flow - I don't like it either... 
Sorry...):

(C) File transfer using the data channel MUST NOT be bundled 
with media and data chunk traffic in the same flow - file 
transfer must use a separate socket creating another flow/5-tuple 
over the network. 
(In reservation type of networks (e.g. mobile OTT, cable), file 
transfer - having no bandwidth limitation - would otherwise 
overflow the reserved bandwidth for media and chunck traffic - 
destroying prioritized delivery of media and chunck traffic 
over that flow.) Such file transfer data channels MUST NOT be 
prioritized by the underlying network (applies to all IP network 
types, network prioritization of file transfer will STOP traffic 
between endpoints
- Endpoint's TCP-like regulation has to function!). Several file 
transfers could share such a separate flow (without specifying in 
SDP I guess) but the underlying network must be able to separate 
such flows (not to be prioritized) from media and chunk flows. 

In the API, such file transfer data channel could be mapped to 
the "below normal" classification (but would it not be better 
with a "file transfer channel" API instead?). (And notice that 
without (D) below, the network is not informed how to separate a 
file transfer data channel flow from a prioritized data channel 
flow.)

 
/Karl

 

TODAY:

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Matthew Kaufman (SKYPE)
Skickat: den 31 mars 2014 19:50
Till: Harald Alvestrand
Kopia: [email-masked]
Ämne: Re: [rtcweb] Some language on "prioritization"

Matthew Kaufman

(Sent from my iPhone)

markings.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2014 10:45:16 -0400

It bothers me to see file transfer singled out for special treatment.

File transfer is one (common) example of a potentially high volume 
stream that has low requirements on latency. There are certainly other 
use cases with similar characteristics that are not file transfers.

If it isn't feasible to manage data channels with differing priority 
needs within the same SCTP association, then why not simply make 
provision for multiple SCTP associations, with a priority for each?

	Thanks,
	Paul

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 22 Apr 2014 00:38:55 +0200

Inline comments/explanations below. /Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Paul Kyzivat
Skickat: den 21 april 2014 16:45
Till: [email-masked]
Ämne: Re: [rtcweb] Some language on "prioritization"

File transfer is one (common) example of a potentially high volume stream
that has low requirements on latency. There are certainly other use cases
with similar characteristics that are not file transfers.

--- When I say "file transfer" I mean ALL traffic of the character "transfer
this high amount of data as fast as possible", which usually is done by TCP,
allowing all "bandwidth left for me at the congestion point" to be used (by
the TCP endpoints regulating their flow to share the available bandwidth at
the congestion point). That cannot be transferred better or with higher
priority, due to its "maximum bandwidth for minimum time" nature. Congestion
always occur - it is the way the available bandwidth is shared (best). That
is what we use TCP for.

--- "Stream" I would reserve for traffic ticking along with time, NOT
filling the pipe. That could be real-time data and be prioritized or
reserved bandwidth for. 

--- If you know your bandwidth at the congestion point (which you don't -
TCP tries it out) you could convert a file transfer into a stream by
spreading it out over time, NOT filling the pipe. But then it would just
take longer time to get the file transferred. File transfer cannot/should
not be prioritized.   

--- These traffic types are different and need to be so.

If it isn't feasible to manage data channels with differing priority needs
within the same SCTP association, then why not simply make provision for
multiple SCTP associations, with a priority for each?

--- Yes multiple SCTP associations are possible as said in (B) below when
file transfer is involved. However, for the sharing of bandwidth at
congestion in the network, such SCTP associations should NOT be bundled over
the same flow/5-tuple as the real-time traffic (=C below). You then need to
set up another ICE connection - That is where I now suggested to do it with
TLS instead (which already is perfect for file transfer) instead of SCTP
(which could be used if working equally well, although much more complex).
Neither can/should prioritize file transfer though.  

	Thanks,
	Paul

On 4/21/14 8:13 AM, Karl Stahl wrote:
> to be created, using TLS file transfer P2P? ICE/STUN/TURN would set it 
> up, NOT BUNDLED with chunk data and RTP media.
>
> Freeing the current rtcweb data channel from file transfer would 
> remedy the self destruction of prioritization/QoS for data chunks and 
> RTP media as explained in (A), (B) and (C) below.
>
> separate p2p file transfer channel (that is not and cannot be 
> prioritized) than pouring files into the data channel.
>
>
> I suggested [2] below, i.e. a new DTLS ContentType for the rtcweb data 
> channel, where the content would be the unencrypted traffic info 
> (preferable the same as in the RTP header extension) followed by the 
> SCTP data.
>
> No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot that 
> DTLS also hold the traffic info, just as for the data chunks
> A way c?) Why not send data chunks in SRTP (instead of SCTP) and reuse 
> the RTP header extension for the traffic info for the network layer. 
> (File transfer is done in 1) above - not here!)
>
> What other things from SCTP do we actually want? (Not everything from 
> that complex protocol for carrying telephony signaling can be of 
> interest for webrtc.)
>
> reliable data chunks could be implemented by the browser (simpler than 
> SCTP).
>
> So with this way c, SCTP would go away totally and only the RTP header 
> extension would be used for traffic info to the network layer.
>
>
channel.
> Right? Reusing the same channel to transfer a series of files should 
> be fine.
>
> 	Thanks,
> 	Paul
> just be taken out of the data channel, and a file transfer channel (on 
> a separate flow, as suggested above) be defined for Web programmers to 
> use. That would remedy (A), (B) and (C) below (p2p file transfer not 
> destroying priority for data chunks and media).
> protocol cannot rearrange the queue. First when that unreachable queue 
> is full, there is something in the endpoint to act upon...
>
>
> There are below (A), (B) and (C) - to get us back to normal - then 
> there is (D) to improve - to allow the network level to give us the 
> prioritization required for WebRTC critical traffic (real-time and 
> data chunks). Without (D) - an interface to network QoS equipment - 
> the network does not even know what to prioritize.
>
> prioritization/quality functionality that simply are not there (cannot 
> be there)? (I have browsed the (complex) SCTP spec and some rtcweb 
> drafts to get an understanding of the prioritization/QoS thoughts and 
> means in this rtcweb context and the intended usage. Is there an 
> endpoints as quickly as possible - CANNOT be prioritized over IP 
> networks! For file transfer we normally use TCP, meaning we fill the 
> pipe, until THE ENDPOINTS see packet drop and regulate down their 
> traffic flow. File transfer over IP networks works this way and cannot 
> be improved upon ("Internet would stop" if we prioritized such 
> traffic! The available bandwidth at congestion points are shared 
> between everyone's TCP-flows hitting such congestion points in the 
> network.) File transfer's nature is to have "infinite bandwidth 
> demand" - the mechanism to handle this is to allow file transfer to 
> "take the rest of the bandwidth"
> The improvement to make - prioritization of media traffic and data 
> chunks - is to allow level 3 QoS methods - not only relying on the 
> level 4 TCP backing off process. Without level 3 QoS (diffserve/DSCP, 
> reservation or separate pipes) media and data chunks packets are also 
> lost in the level 4 TCP backing off process (=today's situation over 
> best effort Internet). That is where the prioritization/QoS measures 
> that we need for rtcweb have to be.
>
> SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve 
> things. It can destroy though if wrongly/badly implemented or used!
>
> chunks expected to have prioritized delivery (otherwise, as per above, 
> SCTP will regulate the "the entire association"
> self-destroying the expected prioritized delivery of data chunks in 
> the same channel).
>
> everyone else's flows at that congestion point
> - That would be "negative priority" compared to what we are used to in 
> a browser.).
>
> media and data chunk traffic in the same flow - file transfer must use 
> a separate socket creating another flow/5-tuple over the network.
> prioritized delivery of media and chunck traffic over that flow.) Such 
> file transfer data channels MUST NOT be prioritized by the underlying 
> network (applies to all IP network types, network prioritization of 
> file transfer will STOP traffic between endpoints
> transfers could share such a separate flow (without specifying in SDP 
> I guess) but the underlying network must be able to separate such 
> flows (not to be prioritized) from media and chunk flows.
>
> "below normal" classification (but would it not be better with a "file 
> transfer channel" API instead?). (And notice that without (D) below, 
> the network is not informed how to separate a file transfer data 
> channel flow from a prioritized data channel
> flow.)
>
>
> Having (A), (B) and (C) in place we are BACK TO THE CURRENT Internet 
> prioritization/QoS level - before the rtcweb p2p data channel file 
> transfer was introduced...
>
> (D) The underlying transport network needs to be informed about the 
> traffic requirements.
>
> browser in the RTP header extension [1] depending on codec usage etc. 
> The API classification could be mapped to the "Prioritize X(2 bits)" 
> suggested in [1] below.
>
> browser/application) has to be passed to reservation types of network. 
> Requested prioritization from the API or DSCP bits are not sufficient. 
> The browser knows the bandwidth requirements for codecs, but for data 
> chunks, the application has the knowledge.
> convention - e.g. reserve 200 kbps for data chunks could serve as a 
> compromise (or 4 bandwidths mapped to the API prioritize 
> For a file transfer data channel - prioritization classification does 
> not even apply.
>
>
> Having prioritization over the network cleared, the application should 
> use that transport properly - having media and data chunks transported 
> with prioritization (as produced/inserted), NOT queuing them up, 
> rearranged by protocols or applications and NOT involving file 
> transfer (that has to be unprioritized).
>
> [1] Traffic type information to encode (recreating the idea/intention 
> of the RTP payload type (PT) header that is not available for the 
> network level anymore, by instead having the browser filling the RTP 
> header extension with relevant traffic info that all IP network types 
> can use.), as suggested already October 22. Two parameters to encode 
> B) The quality characteristics for the stream, with the highest bit 
> set to 1, we could allocate a bit each for quality type e.g:
> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay 
> Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, 
> Prioritize X(2 bits), Variation Y(2 bits), that could be combined as 
> required to describe the stream.
>
> And with the highest bit set to 0, there could instead be a number for 
> special usage that does not fit the general description of the 
> individual bits.
>
> Without this information, how could e.g. a reservation type network 
> (e.g. mobile OTT and cable) reserve the bandwidth required for 
> incoming rtcweb media or data chunks from a diffserve network 
> (carrying no bandwidth requirement)?
>
>
> Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 
> byte Encrypted application data: ...... = the SCTP
>
> Content Type: 24 (1 byte) content type 24 meaning “application data 
> preceded by traffic info”
> Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 
> byte: length of the encrypted application data after the new header 
> extension TRAFFIC INFO, Same as suggested for the RTP Header 
> extension:
> And if SCTP and RTP have packets to send, which goes first, why, and 
> under what circumstances?
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>>>>> specifies a priority policy, but it's about discarding packets, 
>>>>> not deciding which packets to send first, and it also makes it 
>>>> are particular time-sensitive control messages that need to be 
>>>> given higher priority, but this is all time-sensitive.
>>> for all data channels, but things get complicated when when some 
>>> data channels would have different priorities requiring different 
>>> DSCP
> markings.
>>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Apr 2014 09:46:24 -0400

> it up, NOT BUNDLED with chunk data and RTP media.

RFC6062 knows nothing about WebRTC or TLS inside the peer connection
payload. So it doesn't explicitly "allow" what you suggest. But I guess
it doesn't prevent it either. It doesn't care.

> than pouring files into the data channel.

Why do you think using a separate channel would eliminate the issue of
prioritization? We would end up with multiple channels contending for
the same bandwidth. You have just moved the problem one level up. And
made things needlessly more complex, IMHO.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2014 14:36:41 -0400

On 4/21/14 6:38 PM, Karl Stahl wrote:
> this high amount of data as fast as possible",

OK. So you are really talking about a usage with a particular traffic class.

> which usually is done by TCP,

ISTM that avoiding setting up another 5-tuple, with the trouble of ICE, 
etc. is one of the goals. The data channels give you a cheap and easy 
way to set up these things.

IIUC there is already a desire/intent to mark the different streams 
within a bundle as different priorities/traffic classes. (I thought that 
is what DART is about.) Isn't that good enough to achieve the same end 
as running the data over a different 5-tuple?

Apparently there is a problem with doing that at the data channel level. 
But I wouldn't think it would be a problem for multiple SCTP 
associations in the same bundle. (Different SCTP port numbers.) That 
would allow you to have one association for "file transfers" and one for 
more interactive data.

	Thanks,
	Paul

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 23 Apr 2014 07:10:29 +0200

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 22 april 2014 15:46
Till: Karl Stahl; 'Pal Martinsen (palmarti)'; 'Harald Alvestrand'; 'Magnus
Westerlund'
Kopia: [email-masked]
Ämne: Re: SV: [rtcweb] Some language on "prioritization"

RFC6062 knows nothing about WebRTC or TLS inside the peer connection
payload. So it doesn't explicitly "allow" what you suggest. But I guess it
doesn't prevent it either. It doesn't care.

[Karl] OK (just realized TURN was not limited to setting up UDP with
TURN-TCP RFC6062 now available), so meant "allow" in the sense: Fine, we can
use TLS for file-transfer, rather than new/complex UDP with DTLS with SCTP. 

Why do you think using a separate channel would eliminate the issue of
prioritization? We would end up with multiple channels contending for the
same bandwidth. You have just moved the problem one level up. And made
things needlessly more complex, IMHO.

[Karl] The (A) and (B) and (C) at the bottom in the email you answered
DESTROYS the QoS/Prioritization we are used over the Internet (By SCTP data
channel mixing real-time stream data with filling the pipe (congesting
creating) file transfer data in the same bundle/flow/5-tuple).

SCTP's own prioritization mechanism can only act on what is in the
endpoint's buffers - SCTP cannot help/remedy congestion happening IN THE
NETWORK where its data transfer has caused congestion when competing with
other parties file transfer TCP flows, and there filled a network buffer
with the mixture of our own file transfer AND REAL-TIME data. 

Yes, pouring a file into current data channel will even cause QoS damage to
our own bundled Video/Voice that SCTP's prio-mechanism cannot fix, because
it cannot rearrange what is queued up in a Network buffer.

First after getting back to having file transfer separated out of the bundle
in another flow/5-tuple can we start thinking about improving
prioritization/QoS for real-time data.

[Karl] I wrote this sometime before, regarding how QoS over the internet
works in general - may be useful for understanding

For better understanding of these QoS/QoE problems, and methods for
improving (not specifically discussing the policies of sharing real-time
traffic space), I would like to explain:

Over an IP pipe only used for real-traffic (no TCP data traffic), it is
sufficient that the pipe is wide enough for good QoS. That is often used and
implemented by separating IP pipes at a lower level using e.g. Ethernet
VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can
enforce real-traffic into such pipes and QoS is achieved. Let’s call this
Level 2 QoS (Network level)

Over an IP pipe shared between quality requiring real-time traffic and less
demanding data or streaming (usually TCP) traffic, we have the sharing
between these two traffic classes to consider. The main method (and the
mechanism making today’s real-time QoE as good as it often is) is that TCP
endpoints back-off and share their bandwidth usage. Real-time traffic using
UDP transport do not back-off, the endpoints using UDP occupy the bandwidth
needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth
usage that is back-off and shared between them, leaving room for the UDP
traffic. This is mechanism we experience everyday over the Internet, using
our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level)

However, this Level 4 QoS is based on that at congestion times (which happen
every time we click – setting up a TCP flow and transferring some amount of
data as quick as possible) the router handling the most narrow part of the
pipe (the congestion point) drop packets. It is this packet dropping that
(i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error
correction/retransmission mechanism) and (ii) destroys the QoE of real-time
traffic. (Both TCP and UDP packets are dropped in this process that is
triggered by flow intensive TCP traffic.)

We need (i) but don’t want (ii) and to improve on this we can e.g. use
diffserve, DSCP bits in IP packets to instruct routers to always forward the
real-time traffic before any unmarked TCP traffic (which usually fills most
of the pipe). Then QoS is then achieved for real-time traffic. This is Level
3 QoS (IP level). The method used is “traffic shaping”: backing off data
traffic, leaving real-time traffic free passage without packet loss.

Here, in TRAM we want to go beyond Level 4 QoS (already available and
working as good as it can on the Internet), to give quality demanding WebRTC
real-time traffic better QoE by:
a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using
auto-discovered TURN servers) 
or
b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using
auto-discovered TURN servers). Here we must have traffic shaping mechanisms
working, and with correct and sufficient information to do the job. This is
why we in TRAM discuss DISCUSS/MALICE,
draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the
payload type (PT) idea/intent in RTP packets (by now conveying bandwidth and
traffic type in the RTP extension header
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html.

How these QoS/QoE things are done and used in practice is also
illustrated/exemplified in this email discussion:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html 

Prioritization of individual real-time packets (e.g. using diffserve DSCP
bits) have today little impact on the QoE, UNLESS a pipe full with only
real-time traffic (which is unusual), because in today’s IP pipes with high
bandwidth, packets are not stored for later delivery, but rather dropped by
routers implementing diffserve (after only a short time period = small
buffer size). The only good remedy is higher bandwidth, that can handle ALL
real-time traffic. 

Prioritization of real-time packets (any diffserve DSCP bits marking) “makes
QoS perfect”, when there are best effort (=no DSCP bits set) TCP (=non
real-time) traffic going over the IP pipe that can be pushed off. Routers
implementing diffserve do that.

Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 23 Apr 2014 07:19:22 +0200

-----Ursprungligt meddelande-----
Från: Paul Kyzivat [mailto:[email-masked]] 
Skickat: den 22 april 2014 20:37
Till: Karl Stahl; [email-masked]
Ämne: Re: SV: [rtcweb] Some language on "prioritization"

On 4/21/14 6:38 PM, Karl Stahl wrote:
> --- When I say "file transfer" I mean ALL traffic of the character 
> "transfer this high amount of data as fast as possible",

[Karl] Yes

> allowing all "bandwidth left for me at the congestion point" to be 
> used (by the TCP endpoints regulating their flow to share the 
> available bandwidth at the congestion point). That cannot be 
> transferred better or with higher priority, due to its "maximum 
> bandwidth for minimum time" nature. Congestion always occur - it is 
> the way the available bandwidth is shared (best). That is what we use TCP
for.
> --- If you know your bandwidth at the congestion point (which you 
> don't - TCP tries it out) you could convert a file transfer into a 
> stream by spreading it out over time, NOT filling the pipe. But then 
> it would just take longer time to get the file transferred. File 
> transfer cannot/should not be prioritized.
>
> --- Yes multiple SCTP associations are possible as said in (B) below 
> when file transfer is involved. However, for the sharing of bandwidth 
> at congestion in the network, such SCTP associations should NOT be 
> bundled over the same flow/5-tuple as the real-time traffic (=C 
> below). You then need to set up another ICE connection - That is where 
> I now suggested to do it with TLS instead (which already is perfect 
> for file transfer) instead of SCTP (which could be used if working equally
well, although much more complex).
> Neither can/should prioritize file transfer though.

ISTM that avoiding setting up another 5-tuple, with the trouble of ICE, etc.
is one of the goals. 
[Karl] Yes, that goal will unfortunately have to be sacrificed 

The data channels give you a cheap and easy way to set up these things.

IIUC there is already a desire/intent to mark the different streams within a
bundle as different priorities/traffic classes. (I thought that is what DART
is about.) 
[Karl] For whom to act upon? At the network level? Do you have a pointer?

Isn't that good enough to achieve the same end as running the data over a
different 5-tuple?
[Karl] Nope, I don't think reservation type of networks could do that even
with very complex network equipment doing reservations (which I believe is
per flow). 

Apparently there is a problem with doing that at the data channel level. 
But I wouldn't think it would be a problem for multiple SCTP associations in
the same bundle. (Different SCTP port numbers.) That would allow you to have
one association for "file transfers" and one for more interactive data.
[Karl] Still one flow/5-tuple for one bundle - I also wish there was a way
around that

	Thanks,
	Paul

>> 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN 
>> DATA CHANNEL
>>
>> Simon,
>>
>> After looking how to mark data channel priority data chunks 
>> similarly, I suggested [2] below, i.e. a new DTLS ContentType for the 
>> followed by the SCTP data.
>>
layer.
>> Just checking... since there's been no comment to the main body of 
>> the text here (it's all been on the SCTP aspect), is it OK to include 
>> the text in my next version of the -transport draft?
>>
>> applications without considering the transport network (The 
>> congestion to handle by prioritization is in the network - NOT in the
endpoints)!
>> rtcweb drafts to get an understanding of the prioritization/QoS 
>> thoughts and means in this rtcweb context and the intended usage. Is 
>> there an overall design/thought somewhere that I missed/am unaware 
>> of?)
>>
>> traffic flow. File transfer over IP networks works this way and 
>> cannot be improved upon ("Internet would stop" if we prioritized such 
>> above, SCTP will regulate the "the entire association"
>> - That would be "negative priority" compared to what we are used to 
>> in a browser.).
>>
>> for special usage that does not fit the general description of the 
>> individual bits.
>>
>>>> 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.
>>>