Re: [rtcweb] Some language on "prioritization"

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

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".
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

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