Re: [rtcweb] Some language on "prioritization"

[Paul Kyzivat <[e-mail]>]

On 4/21/14 6:38 PM, Karl Stahl wrote:
> Inline comments/explanations below. /Karl
>
> -----Ursprungligt meddelande-----
> Från: rtcweb [mailto:[e-mail]] För Paul Kyzivat
> Skickat: den 21 april 2014 16:45
> Till: [e-mail]
> Ä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

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