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>
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 > >
- [rtcweb] Some language on "prioritization" Harald Alvestrand
- Re: [rtcweb] Some language on "prioritization" Martin Thomson
- Re: [rtcweb] Some language on "prioritization" Michael Tuexen
- Re: [rtcweb] Some language on "prioritization" Harald Alvestrand
- Re: [rtcweb] Some language on "prioritization" Matthew Kaufman (SKYPE)
- Re: [rtcweb] Some language on "prioritization" Karl Stahl
- Re: [rtcweb] Some language on "prioritization" Michael Tuexen
- Re: [rtcweb] Some language on "prioritization" Harald Alvestrand
- Re: [rtcweb] Some language on "prioritization" Michael Tuexen
- Re: [rtcweb] Some language on "prioritization" Jeremy Laurenson (jlaurens)
- Re: [rtcweb] Some language on "prioritization" Michael Tuexen
- Re: [rtcweb] Some language on "prioritization" Harald Alvestrand
- Re: [rtcweb] Some language on "prioritization" Paul Kyzivat
- Re: [rtcweb] Some language on "prioritization" Karl Stahl
- Re: [rtcweb] Some language on "prioritization" Michael Tuexen
- Re: [rtcweb] Some language on "prioritization" Harald Alvestrand
- Re: [rtcweb] Some language on "prioritization" Karl Stahl
- Re: [rtcweb] Some language on "prioritization" Paul Kyzivat
- Re: [rtcweb] Some language on "prioritization" Karl Stahl
- Re: [rtcweb] Some language on "prioritization" Simon Perreault
- Re: [rtcweb] Some language on "prioritization" Paul Kyzivat
- Re: [rtcweb] Some language on "prioritization" Karl Stahl
- Re: [rtcweb] Some language on "prioritization" Karl Stahl