Re: [rtcweb] Some language on "prioritization"

"Karl Stahl" <> Wed, 23 April 2014 05:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C57471A0063 for <>; Tue, 22 Apr 2014 22:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BuOapmr0uKFv for <>; Tue, 22 Apr 2014 22:19:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 88B2E1A0062 for <>; Tue, 22 Apr 2014 22:19:26 -0700 (PDT)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201404230719187241; Wed, 23 Apr 2014 07:19:18 +0200
From: Karl Stahl <>
To: 'Paul Kyzivat' <>,
References: <> <> <>, <> <> <00af01cf4f59$fa617b90$ef2472b0$> <020501cf5d5b$117e9830$347bc890$> <> <024901cf5db2$7ac4bf70$704e3e50$> <>
In-Reply-To: <>
Date: Wed, 23 Apr 2014 07:19:22 +0200
Message-ID: <000701cf5eb3$960aa270$c21fe750$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9eWc6zSxlXSPjiRUCXG6dEzUJp/gAWJqqg
Content-Language: sv
Subject: Re: [rtcweb] Some language on "prioritization"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Apr 2014 05:19:32 -0000

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

On 4/21/14 6:38 PM, Karl Stahl wrote:
> Inline comments/explanations below. /Karl
> -----Ursprungligt meddelande-----
> Från: rtcweb [] För Paul Kyzivat
> Skickat: den 21 april 2014 16:45
> Till:
> Ämne: Re: [rtcweb] Some language on "prioritization"
> 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.
> --- When I say "file transfer" I mean ALL traffic of the character 
> "transfer this high amount of data as fast as possible",

OK. So you are really talking about a usage with a particular traffic class.
[Karl] Yes

> 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
> --- "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.

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
> On 4/21/14 8:13 AM, Karl Stahl wrote:
>> 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.
>> 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
>> (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 [] 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 [] 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
>> []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
>> 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 [] För Karl Stahl
>> Skickat: den 3 april 2014 18:30
>> Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus Westerlund'
>> Kopia:
>> Ä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
>> 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) 
>> 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 
>> 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).:
>> 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
>> 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 [] För Matthew Kaufman
>> (SKYPE)
>> Skickat: den 31 mars 2014 19:50
>> Till: Harald Alvestrand
>> Kopia:
>> Ä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"
>>> <>
>> wrote:
>>>> On 03/31/2014 07:42 PM, Michael Tuexen wrote:
>>>>> On 31 Mar 2014, at 19:38, Martin Thomson 
>>>>> <>
>> wrote:
>>>>>> On 31 March 2014 10:08, Harald Alvestrand <>
> 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
> _______________________________________________
> rtcweb mailing list