Re: [rtcweb] Some language on "prioritization"

[Michael Tuexen <[e-mail]>]

On 03 Apr 2014, at 18:30, Karl Stahl <[e-mail]> wrote:

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