Re: [rtcweb] Some language on "prioritization"

Paul Kyzivat <> Tue, 22 April 2014 18:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 287281A0226 for <>; Tue, 22 Apr 2014 11:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kh1a5wrdR223 for <>; Tue, 22 Apr 2014 11:36:48 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:32]) by (Postfix) with ESMTP id D30621A022B for <>; Tue, 22 Apr 2014 11:36:47 -0700 (PDT)
Received: from ([]) by with comcast id t5DE1n0030xGWP8536ciXe; Tue, 22 Apr 2014 18:36:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id t6ch1n00c3ZTu2S3Y6chem; Tue, 22 Apr 2014 18:36:42 +0000
Message-ID: <>
Date: Tue, 22 Apr 2014 14:36:41 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Karl Stahl <>,
References: <> <> <>, <> <> <00af01cf4f59$fa617b90$ef2472b0$> <020501cf5d5b$117e9830$347bc890$> <> <024901cf5db2$7ac4bf70$704e3e50$>
In-Reply-To: <024901cf5db2$7ac4bf70$704e3e50$>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1398191802; bh=cmM2VKX6xR50PK9m/9iIgL/npzHihcddq4WDEHj/VpE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sQ6SYIiWIphXLoJIbETyKCc1NVnZkeaEtnsP/HFx0JlFCxRrdBOAqMk+1X60AlAdX 9ctnKZo2B3DNq8WXwHuHoTWM5mV6wEvQn3nn/ywAFfeDxhsuouQdLJdfsN2kD9uKwC lwG5K0d3IYQ52HbBSZwr3i85LaFnhVcoKSICB6tiGfEPZzzKjm8ld+K59Z3yK620ie owVFBwhTkwGIQQ6veKy+ROcYrPzyhDhAJRkxznxj2qp3liK4UhPxel+ty2CrS96k6g 3oGV8VFWwwU4TpvL+Z5WyLOIOFb0aQ0txrizAlpYNiRAxb7tz5ioBG0NK94IBGFVdW idR8hIGpoSGpQ==
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: Tue, 22 Apr 2014 18:36:52 -0000

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.

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

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
> 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 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 [] 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 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)
>> 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