Re: [rtcweb] Some language on "prioritization"

[Paul Kyzivat <[e-mail]>]

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.

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?

	Thanks,
	Paul

On 4/21/14 8:13 AM, Karl Stahl wrote:
> 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".
>>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>