Re: [rtcweb] Some language on "prioritization"

["Karl Stahl" <[e-mail]>]

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 [[e-mail]] 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 [[e-mail]] 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.)

[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
[[e-mail]]wrote:
>Is there an
> 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.
>
[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:[e-mail]] För Karl Stahl
Skickat: den 3 april 2014 18:30
Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus Westerlund'
Kopia: [e-mail]
Ä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.

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:[e-mail]] För Matthew Kaufman (SKYPE)
Skickat: den 31 mars 2014 19:50
Till: Harald Alvestrand
Kopia: [e-mail]
Ä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" <[e-mail]>
wrote:
> 
>> On 03/31/2014 07:42 PM, Michael Tuexen wrote:
>>> On 31 Mar 2014, at 19:38, Martin Thomson <[e-mail]>
wrote:
>>> 
>>>> On 31 March 2014 10:08, Harald Alvestrand <[e-mail]> 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".
>