Re: [rtcweb] Some language on "prioritization"

"Karl Stahl" <karl.stahl@intertex.se> Wed, 23 April 2014 05:19 UTC

Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57471A0063 for <rtcweb@ietfa.amsl.com>; Tue, 22 Apr 2014 22:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuOapmr0uKFv for <rtcweb@ietfa.amsl.com>; Tue, 22 Apr 2014 22:19:27 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2E1A0062 for <rtcweb@ietf.org>; Tue, 22 Apr 2014 22:19:26 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404230719187241; Wed, 23 Apr 2014 07:19:18 +0200
From: "Karl Stahl" <karl.stahl@intertex.se>
To: "'Paul Kyzivat'" <pkyzivat@alum.mit.edu>, <rtcweb@ietf.org>
References: <5339A120.3040909@alvestrand.no> <CABkgnnVUHUx+3wY3Dsi=UvNkUw_Es1apeMSonq7DtEg_3UKRNg@mail.gmail.com> <FBA84C78-FE8E-4FEF-8AD3-CAF24C57E512@lurchi.franken.de>, <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> <53552EFC.3000502@alum.mit.edu> <024901cf5db2$7ac4bf70$704e3e50$@stahl@intertex.se> <5356B6B9.3050505@alum.mit.edu>
In-Reply-To: <5356B6B9.3050505@alum.mit.edu>
Date: Wed, 23 Apr 2014 07:19:22 +0200
Message-ID: <000701cf5eb3$960aa270$c21fe750$@stahl@intertex.se>
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
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OGaZSZ_g5H3QO-8pSJTfhLHpms0
Subject: Re: [rtcweb] Some language on "prioritization"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 05:19:32 -0000

-----Ursprungligt meddelande-----
Från: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] 
Skickat: den 22 april 2014 20:37
Till: Karl Stahl; rtcweb@ietf.org
Ä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 [mailto:rtcweb-bounces@ietf.org] För Paul Kyzivat
> Skickat: den 21 april 2014 16:45
> Till: rtcweb@ietf.org
> Ä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
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. 
[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

> 	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 [pkyzivat@alum.mit.edu] 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 [harald@alvestrand.no] 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
>> [Michael.Tuexen@lurchi.franken.de]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:rtcweb-bounces@ietf.org] För Karl Stahl
>> Skickat: den 3 april 2014 18:30
>> Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus Westerlund'
>> Kopia: rtcweb@ietf.org
>> Ä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:rtcweb-bounces@ietf.org] För Matthew Kaufman
>> (SKYPE)
>> Skickat: den 31 mars 2014 19:50
>> Till: Harald Alvestrand
>> Kopia: rtcweb@ietf.org
>> Ä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"
>>> <harald@alvestrand.no>
>> wrote:
>>>
>>>> On 03/31/2014 07:42 PM, Michael Tuexen wrote:
>>>>> On 31 Mar 2014, at 19:38, Martin Thomson 
>>>>> <martin.thomson@gmail.com>
>> wrote:
>>>>>
>>>>>> On 31 March 2014 10:08, Harald Alvestrand <harald@alvestrand.no>
> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>