From nobody Mon Mar 3 11:28:35 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385CD1A0249 for ; Mon, 3 Mar 2014 11:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 69hxMwybMXwf for ; Mon, 3 Mar 2014 11:28:30 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 280241A021B for ; Mon, 3 Mar 2014 11:28:29 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-03-5314d7daf42e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 23.FA.04249.AD7D4135; Mon, 3 Mar 2014 20:28:26 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Mon, 3 Mar 2014 20:28:25 +0100 Message-ID: <5314D7D9.1080703@ericsson.com> Date: Mon, 3 Mar 2014 19:28:25 +0000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> In-Reply-To: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje6t6yLBBpdb1S1W3/zA5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF0r3jMVPFep6PrxiLGB8b10FyMnh4SAicTFvuPsELaYxIV7 69m6GLk4hASOMEo0T5rEBOEsY5S4u+MOM0gVr4C2xLsXbxlBbBYBFYnV816ygthsAhYSN380 soHYogLBEjsP/GaEqBeUODnzCQuILSIgIvH13E8mEFtYwFHi/oknQDYH0AJbidV/7UBMTgE7 iS+vQ0FMCQFxiZ7GIJBiZgE9iSlXWxghbHmJ5q2zwY4RAjqmoamDdQKj4Cwku2YhaZmFpGUB I/MqRo7i1OKk3HQjg02MwOA7uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGR/fxO+ZUZUV8upM2o2Tv3yaYNAU+z8jl7hRgnPb+4d/qqVcIzDU3Xc+9/ seq7ksi6Xkbm5fdm2rqwbldzXRXm6qz1bhUrR6nD4alvQj51znzycPKEP1fXazV9/e14vXAB e131kZqqzWpfkwtKfHYeEpQt2XGe8YJjWyvPt4yLszQelnrzTdJ/rMRSnJFoqMVcVJwIAHql 4x4MAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/qiBRwlAiddB7UOJQvDi5DTtOPEc Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:28:33 -0000 On 2014-02-17 14:53, Eggert, Lars wrote: > Hi, > > we'd like to start the working group last call for > draft-ietf-rmcat-cc-requirements-02. Please send your feedback to > the list. > I have reviewed the draft and here are my feedback on the draft. 1. Abstract: This document is derived from draft-jesup-rtp-congestion-reqs [I-D.jesup-rtp-congestion-reqs]. I think this can be removed from the abstract. It doesn't appear relevant at this stage to be in the abstract. 2. Section 1 ... and since it's consumed in real time, data delivered late is useless. I agree that is commonly useless, but not always. I don't know if we want to be more precise here and write this as: and since it's consumed in real time, data delivered late is commonly useless. 3. Section 1 Given that this use case is the focus of this document, use cases involving noninteractive media such as YouTube-like video streaming, and use cases using multicast/broadcast-type technologies, are out of scope. I wonder if it is appropriate to use the trademark "YouTube" in this text. I would suggest to remove it. 4. Section 2, Req 1.D: Similarly periodic bursty flows such as DASH or proprietary I would suggest adding a reference to DASH and possibly expand it. 5. Section 2, Req 1.D or may cause a shift in the location of the bottleneck fir the duration of the burst. Spelling fir/for 5. Section 2, Req 3.A A. If possible, it should also share information and adaptation with other non-RTP flows between the same endpoints, such as a WebRTC data channel I would recommend a reference after "WebRTC data channel" 6. Section 2, Req 5.A A. In order to react sufficiently quickly when using RTCP for a backchannel, an RTP profile such as AVPF/SAVPF that allows sufficiently frequent feedback [RFC4585] MUST be used. The references and the RTP Profiles don't align well, I would suggest that this is modified to: A. In order to react sufficiently quickly when using RTCP for a backchannel, an RTP profile such as RTP/AVPF [RFC4585] or RTP/SAVPF [RFC5124] that allows sufficiently frequent feedback MUST be used. 7. Section 2, Req 5 A back channel requirement I don't know if it has been discussed is the need for back channel congestion control. 8. Section 2, Req 6 Flows managed by this algorithm and flows competed against at a bottleneck may have different DSCP markings depending on the type of traffic. A particular bottleneck or section of the network path may or may not honor these markings. A. This talks about DSCP only. What about flow based QoS? Is the not included here as differnet network behaviors would require differnet 5-tuples. The RTP streams could still be under common application control so I wonder if this is relevant? B. I would ad a reference here to DSCP, and maybe you need to include the word Diffserv here. 9. Section 2, Req 6.A A. In WebRTC, a division of packets into 4 classes is envisioned in order of priority: faster-than-audio, audio, video, best-effort, and bulk-transfer. Typically the flows managed by this algorithm would be audio or video in that heirarchy, and feedback flows would be faster-than-audio. This doesn't match what is currently in draft-dhesikan-tsvwg-rtcweb-qos-05. I wonder if this needs to be either generalized or reference this document? 10. Section 2. Another requirement that might be missing and is related to 6.A, but not the same. It is the possibility to indicate the relative priority between multiple streams in the same session context. This doesn't require any QoS, just that the sending application indicates relative priority and that affects how bit-rate gets distributed. Or has the discussion been that it will be the higher layers that do this re-distribution between streams for which one have indication if they can increase or reduce the stream. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Mar 4 07:40:33 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5931A005E for ; Tue, 4 Mar 2014 07:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 LdiE4ViOG-oP for ; Tue, 4 Mar 2014 07:40:25 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D1E881A01DD for ; Tue, 4 Mar 2014 07:40:25 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:2782 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKrS9-000GPE-5g for rmcat@ietf.org; Tue, 04 Mar 2014 09:40:21 -0600 Message-ID: <5315F38E.20200@jesup.org> Date: Tue, 04 Mar 2014 10:38:54 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <5314D7D9.1080703@ericsson.com> In-Reply-To: <5314D7D9.1080703@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/geDZQQkFTMzpojDpvSRxiNwwWJg Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:40:28 -0000 On 3/3/2014 2:28 PM, Magnus Westerlund wrote: > On 2014-02-17 14:53, Eggert, Lars wrote: >> Hi, >> >> we'd like to start the working group last call for >> draft-ietf-rmcat-cc-requirements-02. Please send your feedback to >> the list. >> > I have reviewed the draft and here are my feedback on the draft. Thanks! Sorry I can't be there in person (I'd planned to until a couple of weeks ago). Consider my response to be "ok, will do" to everything I don't mention below. > > > 7. Section 2, Req 5 > > A back channel requirement I don't know if it has been discussed is > the need for back channel congestion control. This has been discussed, and the draft mentions that RTCP backchannel messages may be delayed due to RTCP bandwidth rules, and that bandwidth should be limited. It also mentions that this is a flexible area for design and different approaches to backchannels are expected to be considered. I think that's enough to cover it. > > 8. Section 2, Req 6 > > Flows managed by this algorithm and flows competed against at a > bottleneck may have different DSCP markings depending on the > type of traffic. A particular bottleneck or section of the > network path may or may not honor these markings. > > A. This talks about DSCP only. What about flow based QoS? Is the not > included here as differnet network behaviors would require differnet > 5-tuples. The RTP streams could still be under common application > control so I wonder if this is relevant? If you want to propose something specific, please do. "Is the not included here" is confusing... Mostly this is just a warning that we can't rely on markings to be honored, even if they're honored on one part of the path. Also s/competed/competing/ > > 9. Section 2, Req 6.A > > A. In WebRTC, a division of packets into 4 classes is > envisioned in order of priority: faster-than-audio, audio, > video, best-effort, and bulk-transfer. Typically the flows > managed by this algorithm would be audio or video in that > heirarchy, and feedback flows would be faster-than-audio. > > This doesn't match what is currently in > draft-dhesikan-tsvwg-rtcweb-qos-05. I wonder if this needs to be > either generalized or reference this document? We can reference the document and make it align. > > 10. Section 2. > > Another requirement that might be missing and is related to 6.A, but > not the same. It is the possibility to indicate the relative priority > between multiple streams in the same session context. This doesn't > require any QoS, just that the sending application indicates relative > priority and that affects how bit-rate gets distributed. Or has the > discussion been that it will be the higher layers that do this > re-distribution between streams for which one have indication if they > can increase or reduce the stream. See section 3. Perhaps something there along the lines of "When there are multiple streams across the same 5-tuple coordinating their bandwidth use and congestion control, it should be possible for the application to control the relative split of available bandwidth." -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Mar 4 07:46:55 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA891A00F5 for ; Tue, 4 Mar 2014 07:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 8IdBP6suL_KQ for ; Tue, 4 Mar 2014 07:46:51 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EE9AF1A00B9 for ; Tue, 4 Mar 2014 07:46:50 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:2822 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKrYN-0002Yr-QB for rmcat@ietf.org; Tue, 04 Mar 2014 09:46:47 -0600 Message-ID: <5315F511.1060505@jesup.org> Date: Tue, 04 Mar 2014 10:45:21 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> In-Reply-To: <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/t5GsjsA67WPmu_6nFAETRetlA9M Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:46:53 -0000 On 2/19/2014 5:25 PM, Michael Welzl wrote: > Hi, > > Sorry if I missed this in Randell's responses to the reviews - but this text is still there and should be fixed IMO: > > *** > 2. The algorithm must be fair to other flows, both realtime flows > (such as other instances of itself), and TCP flows, both long- > lived and bursts such as the traffic generated by a typical web > browsing session. Note that 'fair' is a rather hard-to-define > term. > > A. Existing flows at a bottleneck must also be fair to new > flows to that bottleneck, and must allow new flows to ramp > up to a useful share of the bottleneck bandwidth quickly. > *** > > Being fair to other instances of itself is one issue, being "fair" to TCP is another one. The latter is covered by the text about trying to avoid starvation of TCP, so I suggest that this item here should not bring TCP into the mix and only talk about other instances of itself. > > Regarding fairness, I don't think that saying "must be fair" and "Note that 'fair' is hard to define" isn't really useful - we need to be clear about what we mean. (Sub-item A doesn't make the paragraph above it clearer, it just adds a restriction. I have no problem with sub-item A although I think it's unnecessary.) > > I once proposed: "Send at roughly the same rate under similar conditions." > (with more details in a previous email with subject "Fairness", see the list archives). This is why it's hard. Fairness is actually larger than what your statement covers - it implies how it reacts when one side has (say) a 10ms RTT and 10Mbps access links and another flow at the bottleneck has 150ms RTT and 1Mbps. (Exactly *what* happens in that case is tough to define in detail, but it falls under "fairness" and isn't covered by your statement.) And while we have most control over self-fairness, a workable solution to the problem here must coexist "fairly" with other traffic which includes TCP (and DNS, etc). > It has sldo been said that we should mandate RTT-independence too. I'm for it. Mandate as a requirement? Not sure; I wouldn't throw out an otherwise excellent solution that fell down some there in favor of a so-so RTT-independent solution. Goal or a positive point in evaluation? yes. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Mar 4 07:53:36 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ADC1A023E for ; Tue, 4 Mar 2014 07:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 g0iwsa61muMx for ; Tue, 4 Mar 2014 07:53:14 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id A259C1A024C for ; Tue, 4 Mar 2014 07:53:13 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WKreX-0000eC-6l; Tue, 04 Mar 2014 16:53:09 +0100 Received: from dhcp-a0b6.meeting.ietf.org ([31.133.160.182]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WKreW-0003De-N5; Tue, 04 Mar 2014 16:53:09 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: <5315F511.1060505@jesup.org> Date: Tue, 4 Mar 2014 15:53:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 9 sum rcpts/h 18 sum msgs/h 11 total rcpts 13213 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C22853ECD00EF61BE52C27669956C5B5A22391CA X-UiO-SPAM-Test: remote_host: 31.133.160.182 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 8 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/216A3CboufMnchm41OObdJ9toNY Cc: rmcat@ietf.org Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:53:18 -0000 On 4. mars 2014, at 15:45, Randell Jesup wrote: > On 2/19/2014 5:25 PM, Michael Welzl wrote: >> Hi, >>=20 >> Sorry if I missed this in Randell's responses to the reviews - but = this text is still there and should be fixed IMO: >>=20 >> *** >> 2. The algorithm must be fair to other flows, both realtime = flows >> (such as other instances of itself), and TCP flows, both = long- >> lived and bursts such as the traffic generated by a typical = web >> browsing session. Note that 'fair' is a rather = hard-to-define >> term. >>=20 >> A. Existing flows at a bottleneck must also be fair to new >> flows to that bottleneck, and must allow new flows to = ramp >> up to a useful share of the bottleneck bandwidth quickly. >> *** >>=20 >> Being fair to other instances of itself is one issue, being "fair" to = TCP is another one. The latter is covered by the text about trying to = avoid starvation of TCP, so I suggest that this item here should not = bring TCP into the mix and only talk about other instances of itself. >>=20 >> Regarding fairness, I don't think that saying "must be fair" and = "Note that 'fair' is hard to define" isn't really useful - we need to be = clear about what we mean. (Sub-item A doesn't make the paragraph above = it clearer, it just adds a restriction. I have no problem with sub-item = A although I think it's unnecessary.) >>=20 >> I once proposed: "Send at roughly the same rate under similar = conditions." >> (with more details in a previous email with subject "Fairness", see = the list archives). >=20 > This is why it's hard. Fairness is actually larger than what your = statement covers - it implies how it reacts when one side has (say) a = 10ms RTT and 10Mbps access links and another flow at the bottleneck has = 150ms RTT and 1Mbps. (Exactly *what* happens in that case is tough to = define in detail, but it falls under "fairness" and isn't covered by = your statement.) I'm aware of that :-) My point is that a mechanism must *at least* do = what I request here. If it can't achieve a roughly equal rate under = completely similar conditions, we deal with a beast that exhibits a = behavior that we can't do much with. > And while we have most control over self-fairness, a workable solution = to the problem here must coexist "fairly" with other traffic which = includes TCP (and DNS, etc). Yes, for some definition of that... I think trying to nail the fairness = with TCP down into a very specific definition is bound to fail. The = current text with "avoid starving and avoid being starved" seems ok to = me >> It has sldo been said that we should mandate RTT-independence too. = I'm for it. >=20 > Mandate as a requirement? Not sure; I wouldn't throw out an otherwise = excellent solution that fell down some there in favor of a so-so = RTT-independent solution. Goal or a positive point in evaluation? yes. I think the group should have a discussion about this later today. Cheers, Michael From nobody Tue Mar 4 08:05:16 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766691A025E for ; Tue, 4 Mar 2014 08:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 pL0zIjVAnIxH for ; Tue, 4 Mar 2014 08:05:11 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC701A01A8 for ; Tue, 4 Mar 2014 08:04:37 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:2925 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKrpa-000B9r-74 for rmcat@ietf.org; Tue, 04 Mar 2014 10:04:34 -0600 Message-ID: <5315F93B.2060508@jesup.org> Date: Tue, 04 Mar 2014 11:03:07 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> In-Reply-To: <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/H0GR-V_1h4DgG7ELTqh4Kgtq84I Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:05:14 -0000 On 3/4/2014 10:53 AM, Michael Welzl wrote: > On 4. mars 2014, at 15:45, Randell Jesup wrote: > >> On 2/19/2014 5:25 PM, Michael Welzl wrote: >>> I once proposed: "Send at roughly the same rate under similar conditions." >>> (with more details in a previous email with subject "Fairness", see the list archives). >> This is why it's hard. Fairness is actually larger than what your statement covers - it implies how it reacts when one side has (say) a 10ms RTT and 10Mbps access links and another flow at the bottleneck has 150ms RTT and 1Mbps. (Exactly *what* happens in that case is tough to define in detail, but it falls under "fairness" and isn't covered by your statement.) > I'm aware of that :-) My point is that a mechanism must *at least* do what I request here. If it can't achieve a roughly equal rate under completely similar conditions, we deal with a beast that exhibits a behavior that we can't do much with. Ok, as a subset of fairness, I can state something along that way (it's implied by other statements, but this adds a bit more teeth to it). >> And while we have most control over self-fairness, a workable solution to the problem here must coexist "fairly" with other traffic which includes TCP (and DNS, etc). > Yes, for some definition of that... I think trying to nail the fairness with TCP down into a very specific definition is bound to fail. The current text with "avoid starving and avoid being starved" seems ok to me ok >>> It has sldo been said that we should mandate RTT-independence too. I'm for it. >> Mandate as a requirement? Not sure; I wouldn't throw out an otherwise excellent solution that fell down some there in favor of a so-so RTT-independent solution. Goal or a positive point in evaluation? yes. > I think the group should have a discussion about this later today. Ok. I still don't see it as a hard MUST requirement here, but a goal/part of evaluation. Let's see where the discussion goes. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Mar 4 08:26:18 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032791A014D for ; Tue, 4 Mar 2014 08:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 AHiWc2Uwe5mF for ; Tue, 4 Mar 2014 08:26:14 -0800 (PST) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A01A00B9 for ; Tue, 4 Mar 2014 08:26:14 -0800 (PST) Received: from BLU181-W62 ([65.55.116.73]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Mar 2014 08:26:11 -0800 X-TMN: [jASPblSw08MU2WcUGO9r1uAgjFftdyAxPaxQiSJpRBc=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_24c0795b-8849-4951-8c7c-170cab7a2d2b_" From: Bernard Aboba To: "rmcat@ietf.org" Date: Tue, 4 Mar 2014 08:26:10 -0800 Importance: Normal In-Reply-To: <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com>, <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no>, <5315F511.1060505@jesup.org>, <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2014 16:26:11.0238 (UTC) FILETIME=[745DA460:01CF37C6] Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/ETa0jqAFgn4HIJXSB8SKpbwnHiA Subject: [rmcat] Review of draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:26:17 -0000 --_24c0795b-8849-4951-8c7c-170cab7a2d2b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here are my comments on the document. 1. The congestion control algorithm must attempt to provide as-low-=0A= as-possible-delay transit for real-time traffic while still=0A= providing a useful amount of bandwidth=2C even when faced with=0A= intermediate bottlenecks and competing flows. [BA] I am not sure that this requirement is meaningful because of the poten= tial influence of the competing flows. For example=2C when TCP is competin= g withrealtime traffic=2C it will tend to fill the queue to the point of in= ducingloss=2C and there is not much that the RMCAT algorithm can do about t= his - the "attempts" will be in vain. So I would separate the requirement = into multiple parts=2C one stating goals in the absence of competing traffi= c=2C and another part talking about goals in the presence of competing flow= s.=20 There may be=0A= lower limits on the amount of bandwidth that is useful=2C but this= =0A= is largely application-specific and the application may be able=0A= to modify or remove flows in order allow some useful flows to=0A= get enough bandwidth.=20 [BA] There are situations such as scalable video coding where the "lowerlim= it" is not application-specific=2C because it relates to the characteristic= s of the base layer. So in these situations=2C once you have stopped sendi= ngextension layers=2C you only have the base layer=2C whose characteristics= maynot be flexible because of the relationship between the base and extens= ionlayers.=20 A. It should also handle routing changes and interface changes=0A= (WiFi to 3G data=2C etc) which may radically change the=0A= bandwidth available=2C and react quickly=2C especially if there= =0A= is a reduction in available bandwidth. [BA] We need to separate routing and interface changes=2C because routingch= anges are typically invisible to the application=2C whereas interfacechange= s will not be. I would argue that reacting "quickly" to routingtransients = is a non-goal because this is a regular feature of the Internet=2Cand the m= ajor requirement is to be resilient against them. This is oneof the reaso= ns that Circuit Breakers is likely to be ineffective in practice- shutting = down communications and requiring manual intervention inresponse to a routi= ng transient is going to be annoying at best.=20 Interface changes are a distinct issue=2C because information could beprovi= ded (either through use of bw estimates or information relatingto the inter= face itself) that could help reset the parameters of thevideo encoder short= ly after the interface change. =20 C. The algorithm must not overreact to short-term bursts (such=0A= as web-browsing) which can quickly saturate a local-=0A= bottleneck router or link=2C but also clear quickly=2C and=0A= should recover quickly when the burst ends. This is=0A= inherently at odds with the need to react quickly-enough to=0A= avoid queue buildup. [BA] It is also at odds with the ability to react quickly to rate adaptatio= n on wireless networks.=20 D. Similarly periodic bursty flows such as DASH or proprietary=0A= media streaming algorithms may compete in bursts with the=0A= algorithm=2C and may not be adaptive within a burst. They are= =0A= often are layered on top of TCP. The algorithm must avoid=0A= too much delay buildup during those bursts=2C and quickly=0A= recover. Note that this traffic may on an access link=2C or=0A= may cause a shift in the location of the bottleneck fir the=0A= duration of the burst. [BA] I would argue that it is not within the power of the algorithm to avoi= ddelay buildup due to competing flows. They are what they are. The onlyth= ing RMCAT can do is to decide how it wishes to behave in response. A. If possible=2C it should also share information and adaptation= =0A= with other non-RTP flows between the same endpoints=2C such as= =0A= a WebRTC data channel=20 [BA] Cooperative adaptation between RTP and SCTP is a tall order=2C particu= larly since the RMCAT WG is not chartered to work on SCTP congestion contro= l.=20 11. It should be evaluated in how it works both with backbone-router=0A= bottlenecks=2C (asymmetric) local-loop bottlenecks=2C and local-lan= =0A= (WiFi/etc) bottlenecks=2C and in competition with varying numbers= =0A= and types of streams (TCP=2C TCP variants in use=2C LEDBAT=0A= [I-D.ietf-ledbat-congestion]=2C inflexible VoIP UDP flows). [BA] WiFi=2C with its (often broken) rate adaptation is going to be a speci= alchallenge for evaluation=2C because the loss could be due to interference= or poor rate adaptation=2C rather than dueto congestion. I would probably= delete this.=20 = --_24c0795b-8849-4951-8c7c-170cab7a2d2b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here are my comments on the= document.

   1.   The congestion control algorithm must attempt to provide as-=
low-=0A=
        as-possible-delay transit for real-time traffic while still=0A=
        providing a useful amount of bandwidth=2C even when faced with=0A=
        intermediate bottlenecks and competing flows.

[BA] I am not sure that this requirement is meaningful because o=
f the potential influence of the competing flows.  For example=2C when TCP =
is competing with
realti=
me traffic=2C it will tend to fill the queue to the point of inducing
= 
loss=2C and there is not much=
 that the RMCAT algorithm can do about this - the "attempts" will be in vai=
n.  So I would separate the requirement into multiple parts=2C one stating go=
als in the absence of competing traffic=2C and another part talking a<=
/span>bout goals in the presence of competing flows. 

        There may be=0A=
        lower limits on the amount of bandwidth that is useful=2C but this=
=0A=
        is largely application-specific and the application may be able=0A=
        to modify or remove flows in order allow some useful flows to=0A=
        get enough bandwidth. 

[BA] There a=
re situations such as scalable video coding where the "lower
limit" is not application-specific=2C =
because it relates to the characteristics of the base layer.  So in these s=
ituations=2C once you have stopped sending
extension layers=2C you only have the base layer=2C whos=
e characteristics may
=
not be flexible because of the relationship between the base and extension<=
/pre>
layers. 

        A.  It should also handle routing changes and int=
erface changes=0A=
            (WiFi to 3G data=2C etc) which may radically change the=0A=
            bandwidth available=2C and react quickly=2C especially if there=
=0A=
            is a reduction in available bandwidth.

[BA] We need to separate routing and interface changes=2C because r=
outing
changes are typic=
ally invisible to the application=2C whereas interface
changes will not be.  I would argue that rea=
cting "quickly" to routing
transients is a non-goal because this is a regular feature of the Inte=
rnet=2C
and the major re=
quirement is to be resilient against them.   This is one
of the reasons that Circuit Breakers is l=
ikely to be ineffective in practice- shutting down communications and requi=
ring manual intervention in
response to a routing transient is going to be annoying at best. 

Interface changes are a distinct issue=2C becau=
se information could be
=
provided (either through use of bw estimates or information relating
<=
pre class=3D"newpage" style=3D"font-size: 1em=3B margin-top: 0px=3B margin-=
bottom: 0px=3B page-break-before: always=3B">to the interface itself) that =
could help reset the parameters of the
video encoder shortly after the interface change.  

        C.  The algorithm must not overreact to sho=
rt-term bursts (such=0A=
            as web-browsing) which can quickly saturate a local-=0A=
            bottleneck router or link=2C but also clear quickly=2C and=0A=
            should recover quickly when the burst ends.  This is=0A=
            inherently at odds with the need to react quickly-enough to=0A=
            avoid queue buildup.

[BA] It is=
 also at odds with the ability to react quickly to rate adaptation on wirel=
ess networks. 

        D.  Similarly period=
ic bursty flows such as DASH or proprietary=0A=
            media streaming algorithms may compete in bursts with the=0A=
            algorithm=2C and may not be adaptive within a burst.  They are=
=0A=
            often are layered on top of TCP.  The algorithm must avoid=0A=
            too much delay buildup during those bursts=2C and quickly=0A=
            recover.  Note that this traffic may on an access link=2C or=0A=
            may cause a shift in the location of the bottleneck fir the=0A=
            duration of the burst.

[BA] I w=
ould argue that it is not within the power of the algorithm to avoid
<=
pre class=3D"newpage" style=3D"font-size: 1em=3B margin-top: 0px=3B margin-=
bottom: 0px=3B page-break-before: always=3B">delay buildup due to competing=
 flows.  They are what they are.  The only
thing RMCAT can do is to decide how it wishes to behave =
in response.

<= pre class=3D"newpage" style=3D"font-size: 1em=3B margin-top: 0px=3B margin-= bottom: 0px=3B page-break-before: always=3B"> A. If possible=2C it = should also share information and adaptation=0A= with other non-RTP flows between the same endpoints=2C such as= =0A= 
                         =
     a WebRTC data channel 

[BA] Coo=
perative adaptation between RTP and SCTP is a tall order=2C particularly si=
nce the RMCAT WG is not chartered to work on SCTP congestion control. 

   11.  It should be evaluated in how it works =
both with backbone-router=0A=
        bottlenecks=2C (asymmetric) local-loop bottlenecks=2C and local-lan=
=0A=
        (WiFi/etc) bottlenecks=2C and in competition with varying numbers=
=0A=
        and types of streams (TCP=2C TCP variants in use=2C LEDBAT=0A=
        [I-D.ietf-ledbat-congestion]=2C =
inflexible VoIP UDP flows).

[BA] WiFi=2C w=
ith its (often broken) rate adaptation is going to be a specialchallenge for =
evaluation=2C because the loss could be due to interference or poor rate ad=
aptation=2C rather than due
to congestion.  I would probably delete this.




= --_24c0795b-8849-4951-8c7c-170cab7a2d2b_-- From nobody Tue Mar 4 09:04:40 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547FE1A0243 for ; Tue, 4 Mar 2014 09:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 U53PSXBxgK_y for ; Tue, 4 Mar 2014 09:04:34 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 171EE1A0232 for ; Tue, 4 Mar 2014 09:04:23 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WKslO-0003tQ-UJ; Tue, 04 Mar 2014 18:04:18 +0100 Received: from dhcp-a0b6.meeting.ietf.org ([31.133.160.182]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WKslO-0004LB-Cx; Tue, 04 Mar 2014 18:04:18 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: <5315F93B.2060508@jesup.org> Date: Tue, 4 Mar 2014 17:04:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> <5315F93B.2060508@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 10 sum msgs/h 6 total rcpts 13215 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FE2789057B6357AE3014FD0BA438601C1BB92679 X-UiO-SPAM-Test: remote_host: 31.133.160.182 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/jdQEZSfTh-gwJOneiyLF9aB8Yw0 Cc: rmcat@ietf.org Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:04:37 -0000 >>>> It has sldo been said that we should mandate RTT-independence too. = I'm for it. >>> Mandate as a requirement? Not sure; I wouldn't throw out an = otherwise excellent solution that fell down some there in favor of a = so-so RTT-independent solution. Goal or a positive point in evaluation? = yes. >> I think the group should have a discussion about this later today. >=20 > Ok. I still don't see it as a hard MUST requirement here, but a = goal/part of evaluation. Let's see where the discussion goes. So I'm not so concerned about the "throw out an otherwise excellent = solution" thing because you can have an excellent solution and *force* = it to be RTT-independent... it's about changing the controller, e.g. via = using the RTT itself to take it out of the equation - a pretty simple = way to do this was described in this paper which is the oldest = occurrence of this kind of thing I know of: http://www.icir.org/floyd/papers/phase.pdf Check out the beginning of page 37 of the pdf. Cheers, Michael From nobody Wed Mar 5 01:09:38 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D041A02B0 for ; Wed, 5 Mar 2014 01:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 bUUQZeDeB7fO for ; Wed, 5 Mar 2014 01:09:29 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id EC66C1A02F0 for ; Wed, 5 Mar 2014 01:09:24 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id w7so773942qcr.36 for ; Wed, 05 Mar 2014 01:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uemaVzChwMMUCG/YZZ4n1r1UECOD5ExHwTy2Lx0rSy8=; b=lSm5kyvJVh5Wup7kq+mHkjTGZR5TkyeV/1Di+fB/UbJVwC544iywHPQGDxd2JfnXyZ y955x7Go/BA1QuGO9vPxFpS0l2rinFiwuyWUSYumkaPSP5PoXGT8lMMZ8mSDdvHiyOjB MTrfSQbX67KPyy24sqfZi3Cx8ISIlGHLA9WlLai4c5wcI4xi1i4hwA3bzLe/WNR1VHOU vyOvNId9bj2pv2cHpmtA7yVwDf8/z0AF2xaF/Qn1pyrPwmmcaNxZ4JluZ/SkO535yKO6 sAGjoi7pk8bMsKrQp+YZn765EEuRQpEjx4pPnsoBJDLrUOqxJ4Q5XK8y6ThFhMjs6eWY 9RzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uemaVzChwMMUCG/YZZ4n1r1UECOD5ExHwTy2Lx0rSy8=; b=e/IjcPEciAlO+huZF4g0C6sJcC5MqAYa5RF+EhJOay9jaLUqWSh478AAC/x8ixifKJ OmwCqv5nYE2nEiNgr8itjn/BLXzKNYuMQ6aJZ4LlH4WCVWo48ifNF98vvt5rfjc4pS+N Hk9Gwy9dD/f6IRajlZD7A5fhltqRSDc1f3Zzyj8jIGBJUVp4vz/cDhIr10kWJtP4Ndf0 DbecCF3bmeDZ7Nf6hfoVn4RJnUVxEOWa8Dd9p6/OPBTP/X332cgZTBxJ45NLaOGKdJV7 5uMbSHWvSMdrea1FP4MIlJQcRRDOOswk5b9QAaVDvVEUw/HIrw12adwtoWyf0dz2/GQC oYYQ== X-Gm-Message-State: ALoCoQmTWoLIDtB3v0N0e+ReXDBoc/2LWMWs0u+1K9Uk/Fny1tU0ngmvFNzFabSNWwaFmnuXSy/fLOURhcMYYiQIl/nA5sABzM/fiSa2ZKqo9PQqMOEkaD5hI65mqUZ6BSgCvWgAK11ITJe2W6ecGz/2jR81DcQN79/Z6cUwcE2kkT2F8WPVQ1MYLkK8ydd6qD5MgECwEzRK MIME-Version: 1.0 X-Received: by 10.224.4.5 with SMTP id 5mr5118911qap.61.1394010561213; Wed, 05 Mar 2014 01:09:21 -0800 (PST) Sender: holmer@google.com Received: by 10.229.246.69 with HTTP; Wed, 5 Mar 2014 01:09:21 -0800 (PST) In-Reply-To: References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> <5315F93B.2060508@jesup.org> Date: Wed, 5 Mar 2014 10:09:21 +0100 X-Google-Sender-Auth: D65VnB2o5mmkF0UXjcRcxCcs3LM Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c219ea50960d04f3d860e9 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/gO7LG17vfh4Q7pn2Ss1p8-NjpBs Cc: Randell Jesup , rmcat WG Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:09:36 -0000 --001a11c219ea50960d04f3d860e9 Content-Type: text/plain; charset=UTF-8 For delay-based CC I have considered the built-in RTT dependency of ack clocked algorithms a feature. The longer the RTT, the longer it will take for you to have a chance to do something about the queues you are building up. Isn't it right that you should be a bit more careful pumping out your packets in that case? I guess it boils down to what we mean with fairness... Equal rates or equal right to build up queues before backing off. Or maybe I've just gotten this wrong. :) /Stefan On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl wrote: > >>>> It has sldo been said that we should mandate RTT-independence too. > I'm for it. > >>> Mandate as a requirement? Not sure; I wouldn't throw out an otherwise > excellent solution that fell down some there in favor of a so-so > RTT-independent solution. Goal or a positive point in evaluation? yes. > >> I think the group should have a discussion about this later today. > > > > Ok. I still don't see it as a hard MUST requirement here, but a > goal/part of evaluation. Let's see where the discussion goes. > > So I'm not so concerned about the "throw out an otherwise excellent > solution" thing because you can have an excellent solution and *force* it > to be RTT-independent... it's about changing the controller, e.g. via using > the RTT itself to take it out of the equation - a pretty simple way to do > this was described in this paper which is the oldest occurrence of this > kind of thing I know of: > > http://www.icir.org/floyd/papers/phase.pdf > Check out the beginning of page 37 of the pdf. > > Cheers, > Michael > > --001a11c219ea50960d04f3d860e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For delay-based CC I have considered the built-in RTT depe= ndency of ack clocked algorithms a feature. The longer the RTT, the longer = it will take for you to have a chance to do something about the queues you = are building up. Isn't it right that you should be a bit more careful p= umping out your packets in that case?

I guess it boils down to what we mean with fairness... Equal= rates or equal right to build up queues before backing off. Or maybe I'= ;ve just gotten this wrong. :)

/Stefan


O= n Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl <michawe@ifi.uio.no>= wrote:
>>>> It has sldo= been said that we should mandate RTT-independence too. I'm for it.
>>> Mandate as a requirement? =C2=A0Not sure; I wouldn't throw= out an otherwise excellent solution that fell down some there in favor of = a so-so RTT-independent solution. =C2=A0Goal or a positive point in evaluat= ion? =C2=A0yes.
>> I think the group should have a discussion about this later today.=
>
> Ok. =C2=A0I still don't see it as a hard MUST requirement here, bu= t a goal/part of evaluation. =C2=A0Let's see where the discussion goes.=

So I'm not so concerned about the "throw out an otherwise ex= cellent solution" thing because you can have an excellent solution and= *force* it to be RTT-independent... it's about changing the controller= , e.g. via using the RTT itself to take it out of the equation - a pretty s= imple way to do this was described in this paper which is the oldest occurr= ence of this kind of thing I know of:

ht= tp://www.icir.org/floyd/papers/phase.pdf
Check out the beginning of page 37 of the pdf.

Cheers,
Michael


--001a11c219ea50960d04f3d860e9-- From nobody Wed Mar 5 06:36:08 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108C1A020A for ; Wed, 5 Mar 2014 06:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mJYqIkNNjdiv for ; Wed, 5 Mar 2014 06:36:01 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D96D31A066E for ; Wed, 5 Mar 2014 06:35:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,593,1389772800"; d="asc'?scan'208";a="106784293" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 05 Mar 2014 06:35:54 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 06:35:54 -0800 From: "Eggert, Lars" To: "rmcat@ietf.org" Thread-Topic: for discussion: candidate solution evaluation Thread-Index: AQHPOIA2WAzNg5ihJUCeCrNAPqcv9g== Date: Wed, 5 Mar 2014 14:35:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.11] Content-Type: multipart/signed; boundary="Apple-Mail=_6A913C02-7DEA-4E79-A8A5-A32BA300C02D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/qgyP3pfzNZiGbtTN6hEY36A0AwU Subject: [rmcat] for discussion: candidate solution evaluation X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:36:03 -0000 --Apple-Mail=_6A913C02-7DEA-4E79-A8A5-A32BA300C02D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I wanted to put my proposal from the session into writing, so we can = discuss it here. I think we've made some good progress on the evaluation criteria and = scenarios, to where we can begin to discuss the properties of some of = the proposed solution candidate algorithms (on the list and at the next = meeting.) My proposal would be that the proponents of said candidates discuss = among themselves and with Varun to pick a small number of them for = initial evaluation. Varun & co-authors will focus their efforts on = fleshing those out in more detail, and meanwhile, the solution = proponents begin evaluation of the candidates in (at least) those = scenarios. In the next session, we'd begin by having Varun walk the group through = the details of those scenarios, and then see evaluation results for the = various candidates. Because I want to encourage folks to implement and evaluate each others = work* (instead of just their own proposal), I'd like to "reward" those = teams that can show results for at least one competitor - in addition to = their own candidate - with more session time in Toronto. Thoughts? Lars * The reason being that this will result in more directly comparable = numbers, while at the same time improving the quality of the = specifications of the various candidates, because we will verify that = they actually can be implemented based on the textual description. --Apple-Mail=_6A913C02-7DEA-4E79-A8A5-A32BA300C02D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUxc2SNZcnpRveo1xAQJ0MwP9Hh5cEd+AvDo3oLoJli8fqu5qlGI6AvmF DpyjoH3RRB3N0LO9sHiVoGqXefcunS3l+S6PUBDlf5o3HdFc4CUdtlZWPmcm0gWK uQCRB+gjdvMJf3Ay+TqoNBmgWx+YIDPp3O+qRdTTaU2OSOzWIFCTGUY87EciO1iq /HJH7YTuLs8= =4RvR -----END PGP SIGNATURE----- --Apple-Mail=_6A913C02-7DEA-4E79-A8A5-A32BA300C02D-- From nobody Wed Mar 5 08:21:12 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2C1A013A for ; Wed, 5 Mar 2014 08:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 YY-Aft6zg9Iz for ; Wed, 5 Mar 2014 08:21:07 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12B1A0117 for ; Wed, 5 Mar 2014 08:21:07 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-0f-53174eefdc4d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 41.D4.10875.FEE47135; Wed, 5 Mar 2014 17:21:03 +0100 (CET) Received: from [153.88.18.33] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.347.0; Wed, 5 Mar 2014 17:21:02 +0100 Message-ID: <53174EED.5070005@ericsson.com> Date: Wed, 5 Mar 2014 17:21:01 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Eggert, Lars" , "rmcat@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Rve9n3iwwYQ+EYsXr3tYLFbf/MDm wOSxZMlPJo8Zn76wBTBFcdmkpOZklqUW6dslcGVcvC5Q8IK/onXiA5YGxqs8XYycHBICJhK/ b19lhbDFJC7cW8/WxcjFISRwiFHi4KYZzCAJIYGVjBL9/fEgNq+AtsSfc2fAGlgEVCQOHnkB 1MDBwSZgI/F4sR9ImF9AUmJDw26wVlGBKInz514yQbQKSpyc+YQFxBYRcJc4t2YrI4gtLOAk MX3GcSaIVbYSq7ZuBBvPKWAn8fHTNXYQmxkofmHOdRYIW16ieetsZpC1QgK6El0v4yYwCs5C smEWko5ZSDoWMDKvYmTPTczMSS833MQIDMaDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhgFLrR8Fd+fe397Tonkygn/BYKn9r9R7JM2uasg6Zdu/u6z QMLaNva7jzQfikyQfL/16nexM1lOe/zTpd9tcS+880+pyXPrAaV3tUn3FzPKnhYWltn+XLve pcY5cdb+6bv38FrsPenF/NCwa3WKZsbeDZHHZmX9ivutEdnwIX3/7ADrM83vF25TYinOSDTU Yi4qTgQAd7rgoBQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/d6Me11ufXtmnM-vC2DQJaH0PX_o Subject: Re: [rmcat] for discussion: candidate solution evaluation X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:21:10 -0000 On 2014-03-05 15:35, Eggert, Lars wrote: > > My proposal would be that the proponents of said candidates discuss > among themselves and with Varun to pick a small number of them for > initial evaluation. Varun & co-authors will focus their efforts on > fleshing those out in more detail, and meanwhile, the solution > proponents begin evaluation of the candidates in (at least) those > scenarios. The proponents may pick small number of the testcases but they must select the same test cases. But I would like to get input and comments on all the test cases on the list. And we(=the authors) will try to address the comments and concerns in all those test cases in the next version. Otherwise, we run a risk of loosing the non-picked testcases as for some reason those were down prioritized. I personally didn't have any preference when those were written and the indexing of the test case does not show any priority either. I would be interesting to know what the proponents are considering when selecting the test cases. From my experience I can say, if somebody setup the testbed and agree on the attribute values specified in the respective test cases, then running all the test cases and as small number of them should not make much of a difference. > > In the next session, we'd begin by having Varun walk the group > through the details of those scenarios, and then see evaluation > results for the various candidates. In this meeting the focus was on the structure and the list of test cases but in future we definitely have to discuss the details and attribute values in each of the test cases. BR Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Wed Mar 5 09:41:05 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E97A1A066A for ; Wed, 5 Mar 2014 09:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Fg1P409ibHBH for ; Wed, 5 Mar 2014 09:40:58 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFE41A0663 for ; Wed, 5 Mar 2014 09:40:58 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id hl1so4893221igb.1 for ; Wed, 05 Mar 2014 09:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=PlZceCDVtf/eOSo8XLhfMkqPElAqwI3bDeHZ21MRGYQ=; b=mUC7DebRySj+4Uzer41L8UpGRuVnIZi9xFr7hlsbNVmueowj+SZW831yx0u19e8QWN SV8DWcvmn24y2+JhwMzlDdVN1EMru1YkrJpjCR/M2kuZ4SimRKgCv5hVkWMYrdAJrJQM Puj2cbSc1F6K1wycJRQPAPGB63sf9ptd67smz8zMXclp4txZxNxGGPYuPaHXohi37byV 31oZJeZ6tXEw4EyV7v9cDEZrbwbOvDW1e/vT71dETlBZbzsedBRi9q/YOtdN5ybKLjjo EbDwTIOVrdF5ZnMJGvqgtjxe8FEC94/rwMfGR4o56yn2pPXkwDBv63+zw6CHFvy8m3rT e90Q== X-Received: by 10.50.22.210 with SMTP id g18mr36023131igf.19.1394041254362; Wed, 05 Mar 2014 09:40:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.225.98 with HTTP; Wed, 5 Mar 2014 09:40:34 -0800 (PST) In-Reply-To: <53174EED.5070005@ericsson.com> References: <53174EED.5070005@ericsson.com> From: Varun Singh Date: Wed, 5 Mar 2014 17:40:34 +0000 Message-ID: To: Zaheduzzaman Sarker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Pg5TIwjQX5AQZ6mS5VjhrdmoAhM Cc: "rmcat@ietf.org" , "Eggert, Lars" Subject: Re: [rmcat] for discussion: candidate solution evaluation X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:41:02 -0000 Hi all, comments inline. On Wed, Mar 5, 2014 at 4:21 PM, Zaheduzzaman Sarker wrote: > > On 2014-03-05 15:35, Eggert, Lars wrote: >> My proposal would be that the proponents of said candidates discuss >> among themselves and with Varun to pick a small number of them for Those interested in this should drop me a note at varun@comnet.tkk.fi. >> initial evaluation. Varun & co-authors will focus their efforts on >> fleshing those out in more detail, and meanwhile, the solution >> proponents begin evaluation of the candidates in (at least) those >> scenarios. > > > The proponents may pick small number of the testcases but they must selec= t > the same test cases. I concur, whichever tests are picked we should make sure that they are the same. However, I would expect the proponents to run test with different set of attributes. For example, different values of RTT > > But I would like to get input and comments on all the test cases on the > list. And we(=3Dthe authors) will try to address the comments and concern= s in > all those test cases in the next version. Otherwise, we run a risk of > loosing the non-picked testcases as for some reason those were down > prioritized. I personally didn't have any preference when those were writ= ten > and the indexing of the test case does not show any priority either. I wo= uld > be interesting to know what the proponents are considering when selecting > the test cases. > > From my experience I can say, if somebody setup the testbed and agree on = the > attribute values specified in the respective test cases, then running all > the test cases and as small number of them should not make much of a > difference. > > >> >> In the next session, we'd begin by having Varun walk the group >> through the details of those scenarios, and then see evaluation >> results for the various candidates. > > In this meeting the focus was on the structure and the list of test cases > but in future we definitely have to discuss the details and attribute val= ues > in each of the test cases. > The attribute values are not set in stone, they can be changed. We just have to make sure that all the proponents use roughly the same values. Cheers, Varun > BR > > Zahed > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > ANM ZAHEDUZZAMAN SARKER > > > Ericsson AB > Services, Media and Network Features > Laboratoriegr=E4nd 11 > 97128 Lule=E5, Sweden > Phone +46 10 717 37 43 > Fax +46 920 996 21 > SMS/MMS +46 76 115 37 43 > zaheduzzaman.sarker@ericsson.com > www.ericsson.com > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Wed Mar 5 10:32:13 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45031A02F3 for ; Wed, 5 Mar 2014 10:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jimsDueHg77R for ; Wed, 5 Mar 2014 10:32:10 -0800 (PST) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 524121A066E for ; Wed, 5 Mar 2014 10:32:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,593,1389772800"; d="asc'?scan'208";a="311577054" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx1-out.netapp.com with ESMTP; 05 Mar 2014 10:32:06 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 10:32:05 -0800 From: "Eggert, Lars" To: Zaheduzzaman Sarker Thread-Topic: [rmcat] for discussion: candidate solution evaluation Thread-Index: AQHPOIA2WAzNg5ihJUCeCrNAPqcv9prTMueAgAAknIA= Date: Wed, 5 Mar 2014 18:32:05 +0000 Message-ID: <46989C1C-4890-4612-B57D-BBEC54EBA744@netapp.com> References: <53174EED.5070005@ericsson.com> In-Reply-To: <53174EED.5070005@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.21] Content-Type: multipart/signed; boundary="Apple-Mail=_EB1F7483-FCE9-4109-92DD-B76AA5AC6877"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/4HJK-ix2xuaw9w75FCj29MHZMyY Cc: "rmcat@ietf.org" Subject: Re: [rmcat] for discussion: candidate solution evaluation X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:32:11 -0000 --Apple-Mail=_EB1F7483-FCE9-4109-92DD-B76AA5AC6877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2014-3-5, at 16:21, Zaheduzzaman Sarker = wrote: > The proponents may pick small number of the testcases but they must = select the same test cases. yep. > But I would like to get input and comments on all the test cases on = the list. And we(=3Dthe authors) will try to address the comments and = concerns in all those test cases in the next version. Otherwise, we run = a risk of loosing the non-picked testcases as for some reason those were = down prioritized. I personally didn't have any preference when those = were written and the indexing of the test case does not show any = priority either. I would be interesting to know what the proponents are = considering when selecting the test cases. Also agreed. I didn't mean to say that all other activity should stop, = and we will obviously give session time to our other milestones and = individual drafts as needed. Lars --Apple-Mail=_EB1F7483-FCE9-4109-92DD-B76AA5AC6877 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUxdto9ZcnpRveo1xAQJAaAP+LpdtbaazSOlEJdSQDVhG0wXtlaxY7AWw /6Ksc6F1L5n/YQC6wAfXF/ixd248WvAydqFpuq43tmuljjFDpf1tOhLuDorTRvf/ W+tgyllDb2y/+pIGiAJby9aX32IfM2nxnj2CPAtqiVnqErNM2XGaS9dzYl09Qney ThDB9DPNUac= =BJ+Q -----END PGP SIGNATURE----- --Apple-Mail=_EB1F7483-FCE9-4109-92DD-B76AA5AC6877-- From nobody Wed Mar 5 12:11:54 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5B1A04B6 for ; Wed, 5 Mar 2014 12:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 tfJhGV0PZN_n for ; Wed, 5 Mar 2014 12:11:46 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id EF9B11A0549 for ; Wed, 5 Mar 2014 12:11:45 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WLIAG-0003to-Uj; Wed, 05 Mar 2014 21:11:40 +0100 Received: from [130.129.10.25] by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WLIAF-0007pq-W4; Wed, 05 Mar 2014 21:11:40 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_E91E6D1A-EE1D-4C66-8FE1-48D50E1A264B" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: Date: Wed, 5 Mar 2014 20:11:38 +0000 Message-Id: <876FA176-FA9C-4867-BC5A-EDAE58E19A6F@ifi.uio.no> References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> <5315F93B.2060508@jesup.org> To: Stefan Holmer X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 9 sum rcpts/h 29 sum msgs/h 15 total rcpts 13319 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 81C8816A8654DD500A4E7241C402E09CF50877B7 X-UiO-SPAM-Test: remote_host: 130.129.10.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 9 total 62 max/h 11 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/5YzYW4XfDuIrCm_HVBRMQe78gn8 Cc: Randell Jesup , rmcat WG Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:11:53 -0000 --Apple-Mail=_E91E6D1A-EE1D-4C66-8FE1-48D50E1A264B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, you have it right - it's a trade-off. What you say here is indeed = the (only?) counter-argument for RTT-independence. We have to weigh the two against each other. I'm not 100% sure - I mean, your argument *is* valid. I'd still lean = towards RTT-independence but can live with both decisions. Cheers, Michael On 5. mars 2014, at 09:09, Stefan Holmer wrote: > For delay-based CC I have considered the built-in RTT dependency of = ack clocked algorithms a feature. The longer the RTT, the longer it will = take for you to have a chance to do something about the queues you are = building up. Isn't it right that you should be a bit more careful = pumping out your packets in that case? >=20 > I guess it boils down to what we mean with fairness... Equal rates or = equal right to build up queues before backing off. Or maybe I've just = gotten this wrong. :) >=20 > /Stefan >=20 >=20 > On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl = wrote: > >>>> It has sldo been said that we should mandate RTT-independence = too. I'm for it. > >>> Mandate as a requirement? Not sure; I wouldn't throw out an = otherwise excellent solution that fell down some there in favor of a = so-so RTT-independent solution. Goal or a positive point in evaluation? = yes. > >> I think the group should have a discussion about this later today. > > > > Ok. I still don't see it as a hard MUST requirement here, but a = goal/part of evaluation. Let's see where the discussion goes. >=20 > So I'm not so concerned about the "throw out an otherwise excellent = solution" thing because you can have an excellent solution and *force* = it to be RTT-independent... it's about changing the controller, e.g. via = using the RTT itself to take it out of the equation - a pretty simple = way to do this was described in this paper which is the oldest = occurrence of this kind of thing I know of: >=20 > http://www.icir.org/floyd/papers/phase.pdf > Check out the beginning of page 37 of the pdf. >=20 > Cheers, > Michael >=20 >=20 --Apple-Mail=_E91E6D1A-EE1D-4C66-8FE1-48D50E1A264B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = you have it right - it's a trade-off. What you say here is indeed the = (only?) counter-argument for RTT-independence.
We have to weigh the = two against each other.

I'm not 100% sure - I = mean, your argument *is* valid. I'd still lean towards RTT-independence = but can live with both = decisions.

Cheers,
Michael

On 5. mars 2014, at 09:09, Stefan Holmer = <stefan@webrtc.org> = wrote:

For delay-based CC I have considered the = built-in RTT dependency of ack clocked algorithms a feature. The longer = the RTT, the longer it will take for you to have a chance to do = something about the queues you are building up. Isn't it right that you = should be a bit more careful pumping out your packets in that case?

I guess it boils down to what we mean with fairness... = Equal rates or equal right to build up queues before backing off. Or = maybe I've just gotten this wrong. = :)

/Stefan


On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl = <michawe@ifi.uio.no> wrote:
>>>> It has sldo been said that we should mandate = RTT-independence too. I'm for it.
>>> Mandate as a requirement?  Not sure; I wouldn't throw = out an otherwise excellent solution that fell down some there in favor = of a so-so RTT-independent solution.  Goal or a positive point in = evaluation?  yes.
>> I think the group should have a discussion about this later = today.
>
> Ok.  I still don't see it as a hard MUST requirement here, but = a goal/part of evaluation.  Let's see where the discussion = goes.

So I'm not so concerned about the "throw out an otherwise = excellent solution" thing because you can have an excellent solution and = *force* it to be RTT-independent... it's about changing the controller, = e.g. via using the RTT itself to take it out of the equation - a pretty = simple way to do this was described in this paper which is the oldest = occurrence of this kind of thing I know of:

http://www.icir.org/floyd/papers/phase.pdf
Check out the beginning of page 37 of the pdf.

Cheers,
Michael



= --Apple-Mail=_E91E6D1A-EE1D-4C66-8FE1-48D50E1A264B-- From nobody Wed Mar 5 12:30:46 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD1F1A045B for ; Wed, 5 Mar 2014 12:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Efqrl21tbTRW for ; Wed, 5 Mar 2014 12:30:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2D61D1A02C1 for ; Wed, 5 Mar 2014 12:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7382; q=dns/txt; s=iport; t=1394051437; x=1395261037; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oGS/YNAVxHS3GjkCaw8UPdmI6s4KEoLQ1jBA8xYg3Js=; b=gq4InQ/vG77QJBXEK3lzsRxw0YUyCD9+3o9Bw/n8Lpv3yxHspE7NlmF4 pLVj9q2mnUx6eUWBeS/Chct6lPOewVOYokMX7OG/XwAZ/DLi2o/xdjk5p xfmtnvH55FgRDayMTn4j11hBupI/hV2nuSx2vabM4Xn9M4uiKCoLDCcZ2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFACqIF1OtJV2Y/2dsb2JhbABagkIjITtXwQ2BGhZ0giUBAQECAnkQAgEIDgMEAQEBCh0HMhQJCAIEAQ0FCAESh14BDM5hF44gMQYBgySBFASJE6FVgy2CKg X-IronPort-AV: E=Sophos;i="4.97,594,1389744000"; d="scan'208,217";a="308304086" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 05 Mar 2014 20:30:36 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s25KUa3q031437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 20:30:36 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 14:30:36 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: Michael Welzl , Stefan Holmer Thread-Topic: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 Thread-Index: AQHPK+/5W0yOYNlYsEiKSPgfn46BpJq9j6iAgBP+jYCAAAIrgIAAAsuAgAARFYCAAQ2lgIAAuQoA//+el0Y= Date: Wed, 5 Mar 2014 20:30:35 +0000 Message-ID: References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> <5315F93B.2060508@jesup.org> , <876FA176-FA9C-4867-BC5A-EDAE58E19A6F@ifi.uio.no> In-Reply-To: <876FA176-FA9C-4867-BC5A-EDAE58E19A6F@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.13.30] Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA217526B2xmbalnx13ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/mbqieM1Gm0qMArkeHCNV6WhIxQ8 Cc: Randell Jesup , rmcat WG Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:30:44 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA217526B2xmbalnx13ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan: I agree with your argument that the longer the RTT, more careful the flow n= eeds to be in pumping out the packets. But, why would it necessarily transl= ate to a lower portion of bandwidth sharing *at steady state*? Or maybe I = misunderstood you somewhere? Thanks, Xiaoqing ________________________________ From: rmcat [rmcat-bounces@ietf.org] on behalf of Michael Welzl [michawe@if= i.uio.no] Sent: Wednesday, March 05, 2014 2:11 PM To: Stefan Holmer Cc: Randell Jesup; rmcat WG Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 No, you have it right - it's a trade-off. What you say here is indeed the (= only?) counter-argument for RTT-independence. We have to weigh the two against each other. I'm not 100% sure - I mean, your argument *is* valid. I'd still lean toward= s RTT-independence but can live with both decisions. Cheers, Michael On 5. mars 2014, at 09:09, Stefan Holmer > wrote: For delay-based CC I have considered the built-in RTT dependency of ack clo= cked algorithms a feature. The longer the RTT, the longer it will take for = you to have a chance to do something about the queues you are building up. = Isn't it right that you should be a bit more careful pumping out your packe= ts in that case? I guess it boils down to what we mean with fairness... Equal rates or equal= right to build up queues before backing off. Or maybe I've just gotten thi= s wrong. :) /Stefan On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl > wrote: >>>> It has sldo been said that we should mandate RTT-independence too. I'm= for it. >>> Mandate as a requirement? Not sure; I wouldn't throw out an otherwise = excellent solution that fell down some there in favor of a so-so RTT-indepe= ndent solution. Goal or a positive point in evaluation? yes. >> I think the group should have a discussion about this later today. > > Ok. I still don't see it as a hard MUST requirement here, but a goal/par= t of evaluation. Let's see where the discussion goes. So I'm not so concerned about the "throw out an otherwise excellent solutio= n" thing because you can have an excellent solution and *force* it to be RT= T-independent... it's about changing the controller, e.g. via using the RTT= itself to take it out of the equation - a pretty simple way to do this was= described in this paper which is the oldest occurrence of this kind of thi= ng I know of: http://www.icir.org/floyd/papers/phase.pdf Check out the beginning of page 37 of the pdf. Cheers, Michael --_000_E7175A8E3DC14048A7D3020E0338C1FA217526B2xmbalnx13ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan: 

I agree with your argument that the longer the RTT, more careful the f= low needs to be in pumping out the packets. But, why would it necessarily t= ranslate to a lower portion of bandwidth sharing *at steady state*?  O= r maybe I misunderstood you somewhere?

Thanks,
Xiaoqing



From: rmcat [rmcat-bounces@ietf.org] on b= ehalf of Michael Welzl [michawe@ifi.uio.no]
Sent: Wednesday, March 05, 2014 2:11 PM
To: Stefan Holmer
Cc: Randell Jesup; rmcat WG
Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02
No, you have it right - it's a trade-off. What you say here is indeed = the (only?) counter-argument for RTT-independence.
We have to weigh the two against each other.

I'm not 100% sure - I mean, your argument *is* valid. I'd still lean t= owards RTT-independence but can live with both decisions.

Cheers,
Michael


On 5. mars 2014, at 09:09, Stefan Holmer <stefan@webrtc.org> wrote:

For delay-based CC I have considered the built-in RTT depe= ndency of ack clocked algorithms a feature. The longer the RTT, the longer = it will take for you to have a chance to do something about the queues you = are building up. Isn't it right that you should be a bit more careful pumping out your packets in that case?

I guess it boils down to what we mean with fairness... Equal rates or = equal right to build up queues before backing off. Or maybe I've just gotte= n this wrong. :)

/Stefan


On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl <michawe@ifi.uio= .no> wrote:
>>>> It has sldo been said that we should manda= te RTT-independence too. I'm for it.
>>> Mandate as a requirement?  Not sure; I wouldn't throw out= an otherwise excellent solution that fell down some there in favor of a so= -so RTT-independent solution.  Goal or a positive point in evaluation?=  yes.
>> I think the group should have a discussion about this later today.=
>
> Ok.  I still don't see it as a hard MUST requirement here, but a = goal/part of evaluation.  Let's see where the discussion goes.

So I'm not so concerned about the "throw out an otherwise excellent so= lution" thing because you can have an excellent solution and *force* i= t to be RTT-independent... it's about changing the controller, e.g. via usi= ng the RTT itself to take it out of the equation - a pretty simple way to do this was described in this paper which is the = oldest occurrence of this kind of thing I know of:

ht= tp://www.icir.org/floyd/papers/phase.pdf
Check out the beginning of page 37 of the pdf.

Cheers,
Michael



--_000_E7175A8E3DC14048A7D3020E0338C1FA217526B2xmbalnx13ciscoc_-- From nobody Thu Mar 6 01:26:51 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2754F1A019D for ; Thu, 6 Mar 2014 01:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 MJ69k5EW1TsI for ; Thu, 6 Mar 2014 01:26:44 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 509C11A018E for ; Thu, 6 Mar 2014 01:26:43 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-34-53183f4fcf0d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 34.D1.23809.F4F38135; Thu, 6 Mar 2014 10:26:39 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.210]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 10:26:38 +0100 From: Ingemar Johansson S To: "rmcat@ietf.org" , "holmer@google.com" , "l.decicco@poliba.it" , "mascolo@poliba.it" Thread-Topic: Comments on draft-alvestrand-rmcat-congestion-02 Thread-Index: Ac85E2PU6TOD6ZoqTRmcFuWj0MVbhg== Date: Thu, 6 Mar 2014 09:26:38 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31EF93AB@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvja6/vUSwwd7XshZX959jsfh7+hGb Rd+vPewWq29+YHNg8ViwqdRjyZKfTB6bXnUyBzBHcdmkpOZklqUW6dslcGX07L7AVnBPpqJ1 IV8DY694FyMnh4SAiUTL33Z2CFtM4sK99WxdjFwcQgKHGCXu7odxFjNK7Ps9gQ2kik3ARmLl oe+MIAkRgRWMEj1vr7CAJJgFyiSO7DzADGILC1hKNP25ARYXEbCT2HJ2KSOErSdxdu4t1i5G Dg4WARWJZcsLQMK8Ar4S65YeAStnFJCVuP/9HtRIcYlbT+YzQVwnILFkz3lmCFtU4uXjf6wQ tpLEjw2XoOr1JG5MncIGYWtLLFv4mhlivqDEyZlPWCYwisxCMnYWkpZZSFpmIWlZwMiyipE9 NzEzJ73caBMjMB4ObvmtuoPxzjmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamAUnDL3vm5F7nq+sKC/aQGZi7JYvA/05p2Zz5WRwBrUbrPX2WhtiPGXhZaPXqndb7Dk OtghbZHyPbtNtl+omzfQfysLk6zpuzcvG6WZBDacjjO9qcz4IkaommvbmzXLVjOpHpOOOPHj /n2L2AdCS3MO75Q9mhmkYzTFS+BF1espnf/W1S+J+KfEUpyRaKjFXFScCAB+2D2jVQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/KMJvmdXlU31s_4C5Bp6hXvwtdA8 Cc: Ingemar Johansson S , Zaheduzzaman Sarker Subject: [rmcat] Comments on draft-alvestrand-rmcat-congestion-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:26:50 -0000 Hi Had a look at http://www.ietf.org/proceedings/89/slides/slides-89-rmcat-5.p= df . I have done some studies around the problem that FTP starves out the m= edia flow. The algorithm proposed on page 3 seems to do the job. There is however a ri= sk that the algo in itself causes self-inflicted congestion in that it incr= eases a threshold against a measured value(and in the process causes the me= asured value to increase).=20 I have experienced this behavior with another algorithm that I have worked = on for a while, the details are not the same as in your algo but I suspect = that you may get the same problem that I describe. In any case, the solutio= n that I have tried out which seems to work is to blank the video every onc= e in a while and sense the one way delay during these periods. If the one w= ay delay (or RTT) drops consideraby during the blank period then the thres= hold (or gamma in your case) should be reduced. I have tried out a one RTT = blank every 10seconds and it seems to do the job. With that said, it should= be possible to solve the problem I outline above. Another, possibly more complicating matter, which I have not managed to sol= ve is that the media (video) is eventually starved out by FTP if I stick to= reasonable settings in the congestion/flow control. The only way to avoid = this is to make the algorithm very insensitive to packet loss.=20 I believe (hypothesis) that the root cause to this problem is that while th= e FTP has an unlimited source bitrate (there are always bytes available for= the flow control to send if possible), the media has a limited source bitr= ate as it is not possible to queue up too many bytes (delay constraint), ad= d the fact that the media source bitrate can change due to content... The e= ffect of this is that the media sender must become even more opportunistic = when it has data to send than FTP.=20 In my implementation I adjust a beta value (similar to Cubic's beta value) = to control the backoff in case of congestion events. If I set the beta valu= e for very little backoff then I can avoid that media is starved out by FTP= * and even get a fair split of the bandwidth. The problem is also that I in= crease the packet loss rate when the FTP load is removed, this is particula= rly obvious when I use a CoDel AQM in the bottleneck. I believe that I can = see that the packet loss rate increases quite considerably on page 5 in you= r presentation when you switch on AT (right figure), this indicates an aggr= essive behavior.=20 All this is not a rant against your algorithm, rather it makes me wonder ho= w reasonable it is with test cases that involves parallel FTP and media ove= r the same bottleneck. Guess it is Ok to try it out but one can question wh= at weight it should have when a figure of merit or whatever is computed.=20 Comments welcome, even if you punch a hole in my hypothesis above.=20 * I can also allow more video frames to be queued up in the sender to alway= s have data to send but that that causes a higher e2e delay. /Ingemar =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "I was gratified to be able to answer promptly, and I did.=20 I said I didn't know." Samuel Clemens =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From nobody Sun Mar 9 12:29:55 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210501A0383 for ; Sun, 9 Mar 2014 12:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 w-Eve8cKYqyu for ; Sun, 9 Mar 2014 12:29:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 812971A02B7 for ; Sun, 9 Mar 2014 12:29:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C38447C0918 for ; Sun, 9 Mar 2014 20:29:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBYoaNAvAyKA for ; Sun, 9 Mar 2014 20:29:40 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id B433B7C08FD for ; Sun, 9 Mar 2014 20:29:40 +0100 (CET) Message-ID: <531CC124.3000209@alvestrand.no> Date: Sun, 09 Mar 2014 20:29:40 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> <5315F93B.2060508@jesup.org> , <876FA176-FA9C-4867-BC5A-EDAE58E19A6F@ifi.uio.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030604000207000405030302" Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/7E6HtHbtWBKiWKAwp7Xs7gM9tKM Subject: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-requirements-02) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 19:29:53 -0000 This is a multi-part message in MIME format. --------------030604000207000405030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Changing the subject to allow concern separation... On 03/05/2014 09:30 PM, Xiaoqing Zhu (xiaoqzhu) wrote: > Stefan: > > I agree with your argument that the longer the RTT, more careful the > flow needs to be in pumping out the packets. But, why would it > necessarily translate to a lower portion of bandwidth sharing *at > steady state*? Or maybe I misunderstood you somewhere? A longer time to achieve the steady state for long RTT flows is probably a more relevant formulation - I think that's inevitable, or close to it. When the stabilization time is a significant fraction of the total lifetime of the flow, or when it's long compared to the interval between changes in the equilibrium, a long-RTT flow will probably experience worse performance than a short-RTT flow, even if they are RTT-independent at equilibrium. > Thanks, > Xiaoqing > > > > ------------------------------------------------------------------------ > *From:* rmcat [rmcat-bounces@ietf.org] on behalf of Michael Welzl > [michawe@ifi.uio.no] > *Sent:* Wednesday, March 05, 2014 2:11 PM > *To:* Stefan Holmer > *Cc:* Randell Jesup; rmcat WG > *Subject:* Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 > > No, you have it right - it's a trade-off. What you say here is indeed > the (only?) counter-argument for RTT-independence. > We have to weigh the two against each other. > > I'm not 100% sure - I mean, your argument *is* valid. I'd still lean > towards RTT-independence but can live with both decisions. > > Cheers, > Michael > > > On 5. mars 2014, at 09:09, Stefan Holmer > wrote: > >> For delay-based CC I have considered the built-in RTT dependency of >> ack clocked algorithms a feature. The longer the RTT, the longer it >> will take for you to have a chance to do something about the queues >> you are building up. Isn't it right that you should be a bit more >> careful pumping out your packets in that case? >> >> I guess it boils down to what we mean with fairness... Equal rates or >> equal right to build up queues before backing off. Or maybe I've just >> gotten this wrong. :) >> >> /Stefan >> >> >> On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl > > wrote: >> >> >>>> It has sldo been said that we should mandate >> RTT-independence too. I'm for it. >> >>> Mandate as a requirement? Not sure; I wouldn't throw out an >> otherwise excellent solution that fell down some there in favor >> of a so-so RTT-independent solution. Goal or a positive point in >> evaluation? yes. >> >> I think the group should have a discussion about this later today. >> > >> > Ok. I still don't see it as a hard MUST requirement here, but >> a goal/part of evaluation. Let's see where the discussion goes. >> >> So I'm not so concerned about the "throw out an otherwise >> excellent solution" thing because you can have an excellent >> solution and *force* it to be RTT-independent... it's about >> changing the controller, e.g. via using the RTT itself to take it >> out of the equation - a pretty simple way to do this was >> described in this paper which is the oldest occurrence of this >> kind of thing I know of: >> >> http://www.icir.org/floyd/papers/phase.pdf >> Check out the beginning of page 37 of the pdf. >> >> Cheers, >> Michael >> >> > --------------030604000207000405030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Changing the subject to allow concern separation...

On 03/05/2014 09:30 PM, Xiaoqing Zhu (xiaoqzhu) wrote:
Stefan: 

I agree with your argument that the longer the RTT, more careful the flow needs to be in pumping out the packets. But, why would it necessarily translate to a lower portion of bandwidth sharing *at steady state*?  Or maybe I misunderstood you somewhere?

A longer time to achieve the steady state for long RTT flows is probably a more relevant formulation - I think that's inevitable, or close to it. When the stabilization time is a significant fraction of the total lifetime of the flow, or when it's long compared to the interval between changes in the equilibrium, a long-RTT flow will probably experience worse performance than a short-RTT flow, even if they are RTT-independent at equilibrium.

Thanks,
Xiaoqing



From: rmcat [rmcat-bounces@ietf.org] on behalf of Michael Welzl [michawe@ifi.uio.no]
Sent: Wednesday, March 05, 2014 2:11 PM
To: Stefan Holmer
Cc: Randell Jesup; rmcat WG
Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02

No, you have it right - it's a trade-off. What you say here is indeed the (only?) counter-argument for RTT-independence.
We have to weigh the two against each other.

I'm not 100% sure - I mean, your argument *is* valid. I'd still lean towards RTT-independence but can live with both decisions.

Cheers,
Michael


On 5. mars 2014, at 09:09, Stefan Holmer <stefan@webrtc.org> wrote:

For delay-based CC I have considered the built-in RTT dependency of ack clocked algorithms a feature. The longer the RTT, the longer it will take for you to have a chance to do something about the queues you are building up. Isn't it right that you should be a bit more careful pumping out your packets in that case?

I guess it boils down to what we mean with fairness... Equal rates or equal right to build up queues before backing off. Or maybe I've just gotten this wrong. :)

/Stefan


On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
>>>> It has sldo been said that we should mandate RTT-independence too. I'm for it.
>>> Mandate as a requirement?  Not sure; I wouldn't throw out an otherwise excellent solution that fell down some there in favor of a so-so RTT-independent solution.  Goal or a positive point in evaluation?  yes.
>> I think the group should have a discussion about this later today.
>
> Ok.  I still don't see it as a hard MUST requirement here, but a goal/part of evaluation.  Let's see where the discussion goes.

So I'm not so concerned about the "throw out an otherwise excellent solution" thing because you can have an excellent solution and *force* it to be RTT-independent... it's about changing the controller, e.g. via using the RTT itself to take it out of the equation - a pretty simple way to do this was described in this paper which is the oldest occurrence of this kind of thing I know of:

http://www.icir.org/floyd/papers/phase.pdf
Check out the beginning of page 37 of the pdf.

Cheers,
Michael




--------------030604000207000405030302-- From nobody Sun Mar 9 12:32:39 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3DA1A0383 for ; Sun, 9 Mar 2014 12:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 1BrHoDD8aaW6 for ; Sun, 9 Mar 2014 12:32:35 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 413811A0142 for ; Sun, 9 Mar 2014 12:32:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DCE367C0918 for ; Sun, 9 Mar 2014 20:32:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ka-rM8fRAQ9 for ; Sun, 9 Mar 2014 20:32:29 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 032D57C08FD for ; Sun, 9 Mar 2014 20:32:29 +0100 (CET) Message-ID: <531CC1CC.20908@alvestrand.no> Date: Sun, 09 Mar 2014 20:32:28 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rmcat@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/2wBMOxBT4CnFlrF_ihMQEpX1ubY Subject: [rmcat] WGLC review: Harald Alvestrand X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 19:32:37 -0000 Here's my review of draft-ietf-rmcat-cc-requirements-02. I hope it's useful. Summary: Content seems just about ready for IETF Last Call (modulo a few nits). Form needs some work. Structural: I feel two sections are missing: - Term definitions. There’s a pointer to -overview, but many terms are not defined there. Nor is it good to have a normative dependency on -overview outside of WebRTC, since this is going to be hanging around in dependency hell “forever”. Especially the terms “flow” and “fair” seem to be works of art for this memo, but also “starvation”. - Evaluation considerations. This is mainly to have somewhere to move requirement 11 to. Now that we have draft-singh-rmcat-cc-eval adopted as a WG document, this may be deleted as “overtaken by events” - but an informative reference to that document may be a Good Thing. The role of bullets and sub-bullets needs to be managed. Most of the time, bullets give requirements (except when they don’t), and the sub-bullets give additional information to expand on understanding the requirements, or further detail about implementation techniques that can be used to achieve them. But sometimes not. Nits: Section 2 1.C Too many hyphens - web-browsing, local-bottleneck, quickly-enough all need to lose their hyphens. 1.D “are often are layered” -> “are often layered”, “may on an access link” -> “may be on an access link”, “fir” -> “for” 2. Don’t use the “fair” term. Use “behave reasonably”. 3. Commas - “The algorithm should, where possible, merge”. Technical: Flows with different Diffserv PHBs may experience different congestion, so amount of merge needs to be conservative. DSCP markings occur in section 6, but need to be menthined here too. 5. Suggest reformulating the point as “When the streams to be managed are all RTP streams, backchannel information needs to be sent via RTCP or via header extensions in an RTP channel going in the opposite direction.” We then need a sub-bullet noting that there are cases when there is no RTP channel in the opposite direction. 6. A WebRTC doesn’t seem to have settled on these 4 classes; draft-dhesikan doesn’t. General requirement should be that feedback flow has DSCP markings that cause it to travel faster than audio, so that the contribution of jitter in the feedback path to estimate errors is as small as possible. 8. “As best as possible” is not English. “As far as possible”? Define “starvation” somewhere. 10. “both if the initial bandwidth is above or below the bottleneck bandwidth” looks meaningful, but doesn’t parse grammatically. 10.A. “other problems for user experience” is too abstract. Say “Can cause packet loss, which gives other problems for the user experience”. 11 does not belong in requirements. It belongs in evaluation. 12 should relate to bullet 10 - starting a flow and resuming a flow should have some of the same characteristics, including how much you trust previous estimates of capacity to the same destination. From nobody Mon Mar 10 03:28:03 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83F21A0415; Mon, 10 Mar 2014 03:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 w1-t8-KlkmFa; Mon, 10 Mar 2014 03:27:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F32CD1A040F; Mon, 10 Mar 2014 03:27:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140310102750.16972.92958.idtracker@ietfa.amsl.com> Date: Mon, 10 Mar 2014 03:27:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/QN-Wb9A9aDwtlBgqoMYZ1wbN2hc Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-eval-criteria-01.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 10:27:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Evaluating Congestion Control for Interactive Real-time Media Authors : Varun Singh Joerg Ott Filename : draft-ietf-rmcat-eval-criteria-01.txt Pages : 12 Date : 2014-03-10 Abstract: The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-eval-criteria-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-eval-criteria-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 10 03:32:59 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA31A0414; Mon, 10 Mar 2014 03:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 yRveI_-1H0U2; Mon, 10 Mar 2014 03:32:55 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6374D1A040F; Mon, 10 Mar 2014 03:32:55 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id hl1so7879734igb.4 for ; Mon, 10 Mar 2014 03:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9JJMxTxw8ZYsIWnA2EehCcT/Ui64vzNpaLiyDfKfdNE=; b=T18GVrRZJn0osBXG/5yeIS2Bay5TAGvsfYEY9GMP9K3AcHS5twcVJ9lty5S7lA8HuA Od1aKQEjdmRVPlVu+9mKmOygkD/zEazE+7VL06nL0UYR3ri5SPvAKU6RWd0de85JAkXU o1eSU7W7bB38ottK4/xcXP6RPCl7jcJreG7ome/Iy5ycU93KL1gkJEPpPcmzw9rhlx3P 8xmAKvDEQTj7OVVYI4aAgcPhvQJHsyh49gw2qXZokt4ENpUIqYpBNXfZ9dLEGnRP4RK+ 4IxndfG/hUEXSt10r6HkKucgxqsH2yM90pLyRf10toWhqb798aalxv5TmBvBUjaQUsqI vRuA== X-Received: by 10.50.22.210 with SMTP id g18mr17102248igf.19.1394447570099; Mon, 10 Mar 2014 03:32:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.225.98 with HTTP; Mon, 10 Mar 2014 03:32:29 -0700 (PDT) In-Reply-To: <20140310102750.16972.92958.idtracker@ietfa.amsl.com> References: <20140310102750.16972.92958.idtracker@ietfa.amsl.com> From: Varun Singh Date: Mon, 10 Mar 2014 12:32:29 +0200 Message-ID: To: "internet-drafts@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/-FZ38n_wolbMUPl0pWNltoSDBmg Cc: rmcat WG , i-d-announce@ietf.org Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-eval-criteria-01.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 10:32:57 -0000 Hi all, As per the feedback from the meeting in London, I have removed the section on test parameters and scenarios. The test parameters section will be incorporated in the next version of draft-sarker-rmcat-eval-test. Cheers, Varun On Mon, Mar 10, 2014 at 12:27 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. > > Title : Evaluating Congestion Control for Interactive Real-time Media > Authors : Varun Singh > Joerg Ott > Filename : draft-ietf-rmcat-eval-criteria-01.txt > Pages : 12 > Date : 2014-03-10 > > Abstract: > The Real-time Transport Protocol (RTP) is used to transmit media in > telephony and video conferencing applications. This document > describes the guidelines to evaluate new congestion control > algorithms for interactive point-to-point real-time media. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-eval-criteria-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-eval-criteria-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- http://www.netlab.tkk.fi/~varun/ From nobody Mon Mar 10 10:28:22 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3FB1A06C8 for ; Mon, 10 Mar 2014 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 m4l8SW4WNxHc for ; Mon, 10 Mar 2014 10:28:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBC71A06D2 for ; Mon, 10 Mar 2014 10:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10435; q=dns/txt; s=iport; t=1394472486; x=1395682086; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8lemORKN46qkCLGcibABty8/ZLugZ1rj9DNXYx+LwD8=; b=QQbIcfy+wdfAdJE40dzhAhQDQgbK3E93TXtQUQqPZq+a8kCpOI2X2xcH l/Ga3MRLPEVFYWX67DeQLo4cGzReA5YyQlqpTuLdGLsH2Hov7qi1bxE9K 4mgAscY50B8IBc9cNbPrcnk42u6BpQ/42B0AowPufhfrYne/D5E0m1iKE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFABn1HVOtJXG//2dsb2JhbABagkQjIThVvRyBHxYBdIN9AQEBAgKBCQIBCBEEAQEBCh0HMhQJCAIEARIIARKHaQEMxgsXjmE3AYMjgRMEiQuhH4Mrgio X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="306229721" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 10 Mar 2014 17:28:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2AHS47p005322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 17:28:04 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 12:28:04 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: Harald Alvestrand , "rmcat@ietf.org" Thread-Topic: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-requirements-02) Thread-Index: AQHPO83zGIJF4Qg4c0m9ZWpTapeSaprak8gO Date: Mon, 10 Mar 2014 17:28:04 +0000 Message-ID: References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no> <5315F511.1060505@jesup.org> <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> <5315F93B.2060508@jesup.org> , <876FA176-FA9C-4867-BC5A-EDAE58E19A6F@ifi.uio.no> , <531CC124.3000209@alvestrand.no> In-Reply-To: <531CC124.3000209@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.12.145] Content-Type: multipart/alternative; boundary="_000_E7175A8E3DC14048A7D3020E0338C1FA217535F4xmbalnx13ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/8LHB8F1x3eJWYV3rmSywKjHes8Q Subject: Re: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-requirements-02) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:28:17 -0000 --_000_E7175A8E3DC14048A7D3020E0338C1FA217535F4xmbalnx13ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. Then, looks like we are on the same page? we want RTT-independence at equi= librium, and may tolerate RTT-dependence during transit. Best, Xiaoqing ________________________________ From: rmcat [rmcat-bounces@ietf.org] on behalf of Harald Alvestrand [harald= @alvestrand.no] Sent: Sunday, March 09, 2014 1:29 PM To: rmcat@ietf.org Subject: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-require= ments-02) Changing the subject to allow concern separation... On 03/05/2014 09:30 PM, Xiaoqing Zhu (xiaoqzhu) wrote: Stefan: I agree with your argument that the longer the RTT, more careful the flow n= eeds to be in pumping out the packets. But, why would it necessarily transl= ate to a lower portion of bandwidth sharing *at steady state*? Or maybe I = misunderstood you somewhere? A longer time to achieve the steady state for long RTT flows is probably a = more relevant formulation - I think that's inevitable, or close to it. When= the stabilization time is a significant fraction of the total lifetime of = the flow, or when it's long compared to the interval between changes in the= equilibrium, a long-RTT flow will probably experience worse performance th= an a short-RTT flow, even if they are RTT-independent at equilibrium. Thanks, Xiaoqing ________________________________ From: rmcat [rmcat-bounces@ietf.org] on beha= lf of Michael Welzl [michawe@ifi.uio.no] Sent: Wednesday, March 05, 2014 2:11 PM To: Stefan Holmer Cc: Randell Jesup; rmcat WG Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 No, you have it right - it's a trade-off. What you say here is indeed the (= only?) counter-argument for RTT-independence. We have to weigh the two against each other. I'm not 100% sure - I mean, your argument *is* valid. I'd still lean toward= s RTT-independence but can live with both decisions. Cheers, Michael On 5. mars 2014, at 09:09, Stefan Holmer > wrote: For delay-based CC I have considered the built-in RTT dependency of ack clo= cked algorithms a feature. The longer the RTT, the longer it will take for = you to have a chance to do something about the queues you are building up. = Isn't it right that you should be a bit more careful pumping out your packe= ts in that case? I guess it boils down to what we mean with fairness... Equal rates or equal= right to build up queues before backing off. Or maybe I've just gotten thi= s wrong. :) /Stefan On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl > wrote: >>>> It has sldo been said that we should mandate RTT-independence too. I'm= for it. >>> Mandate as a requirement? Not sure; I wouldn't throw out an otherwise = excellent solution that fell down some there in favor of a so-so RTT-indepe= ndent solution. Goal or a positive point in evaluation? yes. >> I think the group should have a discussion about this later today. > > Ok. I still don't see it as a hard MUST requirement here, but a goal/par= t of evaluation. Let's see where the discussion goes. So I'm not so concerned about the "throw out an otherwise excellent solutio= n" thing because you can have an excellent solution and *force* it to be RT= T-independent... it's about changing the controller, e.g. via using the RTT= itself to take it out of the equation - a pretty simple way to do this was= described in this paper which is the oldest occurrence of this kind of thi= ng I know of: http://www.icir.org/floyd/papers/phase.pdf Check out the beginning of page 37 of the pdf. Cheers, Michael --_000_E7175A8E3DC14048A7D3020E0338C1FA217535F4xmbalnx13ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks for the clarification. 

Then, looks like we are on the same page?  we want RTT-independen= ce at equilibrium, and may tolerate RTT-dependence during transit.  

Best,
Xiaoqing

From: rmcat [rmcat-bounces@ietf.org] on b= ehalf of Harald Alvestrand [harald@alvestrand.no]
Sent: Sunday, March 09, 2014 1:29 PM
To: rmcat@ietf.org
Subject: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-= requirements-02)

Changing the subject to allow concern separa= tion...

On 03/05/2014 09:30 PM, Xiaoqing Zhu (xiaoqzhu) wrote:

Hi,

 

The pdf versions of the documents

draft-sarker-rmcat-eval-t= est-00 and draft-ietf-rmcat-cc-requirements-02= ,

seem to be formatted in such a way that a document p= age is split onto two pages.

 

It would be greatly appreciated if the pdf formattin= g of these documents could be fixed.  

 

Br,

Erlendur

 

--_000_4B3BB9C48C026A4FB51BC0E792555962185888ESESSMB109ericsso_-- From nobody Thu Mar 13 02:37:28 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6F1A0925 for ; Thu, 13 Mar 2014 02:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5gabKWnXf6cg for ; Thu, 13 Mar 2014 02:37:25 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0851A090B for ; Thu, 13 Mar 2014 02:37:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,646,1389772800"; d="asc'?scan'208";a="149684095" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 13 Mar 2014 02:37:19 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 02:37:19 -0700 From: "Eggert, Lars" To: Erlendur Karlsson Thread-Topic: [rmcat] Pdf document formatting problems Thread-Index: Ac8+mBa2GPhanA9cScqABXxCqNIuIAAQmgyA Date: Thu, 13 Mar 2014 09:37:17 +0000 Message-ID: References: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> In-Reply-To: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/signed; boundary="Apple-Mail=_4848997A-50D2-4660-9FA8-04D0B9A46F34"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/1IB4DdALUAsRU7q8Yab8oJCRu5Q Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Pdf document formatting problems X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 09:37:27 -0000 --Apple-Mail=_4848997A-50D2-4660-9FA8-04D0B9A46F34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-3-13, at 9:49, Erlendur Karlsson = wrote: > The pdf versions of the documents > draft-sarker-rmcat-eval-test-00 and = draft-ietf-rmcat-cc-requirements-02, > seem to be formatted in such a way that a document page is split onto = two pages. http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf and http://tools.ietf.org/pdf/draft-ietf-rmcat-cc-requirements-02.pdf look = fine here? Lars --Apple-Mail=_4848997A-50D2-4660-9FA8-04D0B9A46F34 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUyF8TdZcnpRveo1xAQLO5gP9EmF/VomcUJ7ztVedw1geyxiYShn+S7aD jyzDNr8IcAbe9uwm/xvOQwyYoKXCceCBazC30/sGC9KN2rqUKj5KEMQjmdQepdJn 7576a2Dt0k2Y8QSqkPbtOTGQne5PGGbsxKu5lg2aDezgZir2W7gMWivm2MtQvnor lzgsRU8hYas= =NQRr -----END PGP SIGNATURE----- --Apple-Mail=_4848997A-50D2-4660-9FA8-04D0B9A46F34-- From nobody Thu Mar 13 05:12:44 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A761A0956 for ; Thu, 13 Mar 2014 05:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 f1_kNTxI7xxT for ; Thu, 13 Mar 2014 05:12:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 107571A0785 for ; Thu, 13 Mar 2014 05:12:37 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-77-5321a0ae33fd Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2E.A5.23809.EA0A1235; Thu, 13 Mar 2014 13:12:30 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 13:12:30 +0100 From: Erlendur Karlsson To: "Eggert, Lars" Thread-Topic: [rmcat] Pdf document formatting problems Thread-Index: Ac8+mBa2GPhanA9cScqABXxCqNIuIAAQmgyAAAnr4zA= Date: Thu, 13 Mar 2014 12:12:29 +0000 Message-ID: <4B3BB9C48C026A4FB51BC0E79255596218599C@ESESSMB109.ericsson.se> References: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvje66BYrBBl3tNhYvXvewWKy++YHN gcljyZKfTB4zPn1hC2CK4rJJSc3JLEst0rdL4Mp4t3QNS8EVjoo9H1eyNjDOY+9i5OSQEDCR 2LvuGZQtJnHh3nq2LkYuDiGBQ4wSK9dNgHKWMEp0/9jA0sXIwcEmYCFx+kEASIOIgIrE5vmn wZqZBVQlJjwHqefkEBYwlVi+9zATSLmIgJnEm8e1EOVWEne2XWcBsVmAytc/28IIYvMKeEtc fjCZFcQWEqiXOLVtMzOIzSlgJ/F11gWwGkag276fWsMEsUpc4taT+UwQNwtILNlznhnCFpV4 +fgfK4StKHF1+nKoeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYxis5CMnYWkZRaSlllIWhYw sqxiZM9NzMxJLzfaxAiMkINbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGE2+tJw6Npl7qkRPr2GWTGDGYrV30RtkOBh/L+96v9ZnLfPSKB5pZ7EwzU8r hCwu8PUsXa9094Hbj59mi/sf5K7af50jPqL71L+u/0+nsDv4Xo968nnDXr8dD50OOXQf2mI8 /ewphxe/5nGd3/i34eOW2/keK8WN4xZcORY25URX7cKTE2y+COQosRRnJBpqMRcVJwIAG5S6 Ml4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/qe47pb1LGfFvzsIqLhR7xVRTmwY Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Pdf document formatting problems X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:12:41 -0000 In both of them I get the foot-line for the first page on top of the second= page, which is empty except for that line. This line offset evolves for th= e following pages. While for other documents such as http://datatracker.iet= f.org/doc/draft-ietf-rmcat-eval-criteria/ I have no problems with the pdf f= ile, the foot-lines for all the pages are exactly where they should. It see= ms they are formatted differently. Br, Erlendur -----Original Message----- From: Eggert, Lars [mailto:lars@netapp.com]=20 Sent: den 13 mars 2014 10:37 To: Erlendur Karlsson Cc: rmcat@ietf.org Subject: Re: [rmcat] Pdf document formatting problems On 2014-3-13, at 9:49, Erlendur Karlsson w= rote: > The pdf versions of the documents > draft-sarker-rmcat-eval-test-00 and=20 > draft-ietf-rmcat-cc-requirements-02, > seem to be formatted in such a way that a document page is split onto two= pages. http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf and http://to= ols.ietf.org/pdf/draft-ietf-rmcat-cc-requirements-02.pdf look fine here? Lars From nobody Thu Mar 13 06:02:00 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C631A07BE for ; Thu, 13 Mar 2014 06:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DtBzC4_zuF_g for ; Thu, 13 Mar 2014 06:01:57 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D18261A088A for ; Thu, 13 Mar 2014 06:01:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,647,1389772800"; d="asc'?scan'208";a="108956829" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 13 Mar 2014 06:01:51 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 06:01:51 -0700 From: "Eggert, Lars" To: Erlendur Karlsson Thread-Topic: [rmcat] Pdf document formatting problems Thread-Index: Ac8+mBa2GPhanA9cScqABXxCqNIuIAAQmgyAAAnr4zD//+nHAA== Date: Thu, 13 Mar 2014 13:01:51 +0000 Message-ID: <36CB1835-ABEC-4384-87F6-FC93B34EBC91@netapp.com> References: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> <4B3BB9C48C026A4FB51BC0E79255596218599C@ESESSMB109.ericsson.se> In-Reply-To: <4B3BB9C48C026A4FB51BC0E79255596218599C@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/signed; boundary="Apple-Mail=_C2726D89-58EA-4ABF-B6CD-AF6AE11A77A4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/SQxzf7QzYeQDBLuTClbIf27W-LI Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Pdf document formatting problems X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:01:59 -0000 --Apple-Mail=_C2726D89-58EA-4ABF-B6CD-AF6AE11A77A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Are you printing them or viewing them on screen? If the former, I suspect a page size issue. Lars On 2014-3-13, at 13:12, Erlendur Karlsson = wrote: > In both of them I get the foot-line for the first page on top of the = second page, which is empty except for that line. This line offset = evolves for the following pages. While for other documents such as = http://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ I have = no problems with the pdf file, the foot-lines for all the pages are = exactly where they should. It seems they are formatted differently. >=20 > Br, > Erlendur >=20 >=20 > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com]=20 > Sent: den 13 mars 2014 10:37 > To: Erlendur Karlsson > Cc: rmcat@ietf.org > Subject: Re: [rmcat] Pdf document formatting problems >=20 > On 2014-3-13, at 9:49, Erlendur Karlsson = wrote: >> The pdf versions of the documents >> draft-sarker-rmcat-eval-test-00 and=20 >> draft-ietf-rmcat-cc-requirements-02, >> seem to be formatted in such a way that a document page is split onto = two pages. >=20 > http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf and = http://tools.ietf.org/pdf/draft-ietf-rmcat-cc-requirements-02.pdf look = fine here? >=20 > Lars >=20 --Apple-Mail=_C2726D89-58EA-4ABF-B6CD-AF6AE11A77A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUyGsPtZcnpRveo1xAQJHXQQAuvuwfWUKROexG+x+EpLKFs9T7ETElqXD eyr1L5MyxnRXQpPeSGp2N1xx4jymZeYIH83Uj7L7L4JhSL6Zf8lPA9gVQX+RUTjW 3oPu9G5kI38k0yrFQOj1mW532m6wWwstZ+aEW4InTTMMmmzyBMp+nEFFOTRPOI3X oWJX9Vz5V9k= =x8Eu -----END PGP SIGNATURE----- --Apple-Mail=_C2726D89-58EA-4ABF-B6CD-AF6AE11A77A4-- From nobody Thu Mar 13 06:38:33 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6891A0848 for ; Thu, 13 Mar 2014 06:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 y4IREux1REOS for ; Thu, 13 Mar 2014 06:38:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE791A08E7 for ; Thu, 13 Mar 2014 06:38:26 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-8b-5321b4cbdc25 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F2.DC.10875.BC4B1235; Thu, 13 Mar 2014 14:38:20 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 14:38:19 +0100 From: Erlendur Karlsson To: "Eggert, Lars" Thread-Topic: [rmcat] Pdf document formatting problems Thread-Index: Ac8+mBa2GPhanA9cScqABXxCqNIuIAAQmgyAAAnr4zD//+nHAIAAbb8w Date: Thu, 13 Mar 2014 13:38:18 +0000 Message-ID: <4B3BB9C48C026A4FB51BC0E792555962185A2E@ESESSMB109.ericsson.se> References: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> <4B3BB9C48C026A4FB51BC0E79255596218599C@ESESSMB109.ericsson.se> <36CB1835-ABEC-4384-87F6-FC93B34EBC91@netapp.com> In-Reply-To: <36CB1835-ABEC-4384-87F6-FC93B34EBC91@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje6ZLYrBBncbOC1evO5hsVh98wOb A5PHkiU/mTxmfPrCFsAUxWWTkpqTWZZapG+XwJUx595FxoLtvBXT+7YxNjC2cncxcnJICJhI bOr/zgphi0lcuLeerYuRi0NI4BCjxJS+L2wgCSGBJYwSa1cGdzFycLAJWEicfhAAEhYRUJHY PP80O4jNLKAqMeH5BLByYQFTieV7DzOBlIsImEm8eVwLYbpJPNkVC1LBAlT97+AssK28At4S S9+uYoTY+pVRYvX/5WAJTgE7idnzLjCB2IxAp30/tYYJYpW4xK0n85kgThaQWLLnPDOELSrx 8vE/qFcUJa5OXw5VryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJG llWM7LmJmTnp5YabGIHxcXDLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDI7/e1hMlDncCX8qdzb3xbH24pF+xyak4hwTrN+q/1TStmpW3xb4+JpjEI+DV cqjUY286wwdl9bch+48lrJM6ILvrrGlU5Ar5JsOcqWmGbUyTtxg9OP92l6WT50KddX3P1vj+ bCpQOPjdb27y0c/xm6OeBAZUsvG/r/wX5PXtXcMnoZ03zXdrKLEUZyQaajEXFScCAPGGARJd AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/PSCe1cSEAO3lVtZwATCREzU8kR0 Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Pdf document formatting problems X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:38:29 -0000 I am viewing them on the screen and it does not matter if it is in a Chrome= browser or Acrobat Reader.=20 Br, Erlendur -----Original Message----- From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: den 13 mars 2014 14:02 To: Erlendur Karlsson Cc: rmcat@ietf.org Subject: Re: [rmcat] Pdf document formatting problems Are you printing them or viewing them on screen? If the former, I suspect a page size issue. Lars On 2014-3-13, at 13:12, Erlendur Karlsson = wrote: > In both of them I get the foot-line for the first page on top of the seco= nd page, which is empty except for that line. This line offset evolves for = the following pages. While for other documents such as http://datatracker.i= etf.org/doc/draft-ietf-rmcat-eval-criteria/ I have no problems with the pdf= file, the foot-lines for all the pages are exactly where they should. It s= eems they are formatted differently. >=20 > Br, > Erlendur >=20 >=20 > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com]=20 > Sent: den 13 mars 2014 10:37 > To: Erlendur Karlsson > Cc: rmcat@ietf.org > Subject: Re: [rmcat] Pdf document formatting problems >=20 > On 2014-3-13, at 9:49, Erlendur Karlsson = wrote: >> The pdf versions of the documents >> draft-sarker-rmcat-eval-test-00 and=20 >> draft-ietf-rmcat-cc-requirements-02, >> seem to be formatted in such a way that a document page is split onto tw= o pages. >=20 > http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf and http://= tools.ietf.org/pdf/draft-ietf-rmcat-cc-requirements-02.pdf look fine here? >=20 > Lars >=20 From nobody Thu Mar 13 09:52:41 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC4B1A09CE for ; Thu, 13 Mar 2014 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 lBUfCx9KWUrH for ; Thu, 13 Mar 2014 09:52:38 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) by ietfa.amsl.com (Postfix) with ESMTP id CBA331A0A0B for ; Thu, 13 Mar 2014 09:52:36 -0700 (PDT) Date: Thu, 13 Mar 2014 17:52:28 +0100 From: Stefan Alfredsson To: "Eggert, Lars" Message-ID: <20140313165228.GA16344@sa-pc.cs.kau.se> References: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> <4B3BB9C48C026A4FB51BC0E79255596218599C@ESESSMB109.ericsson.se> <36CB1835-ABEC-4384-87F6-FC93B34EBC91@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36CB1835-ABEC-4384-87F6-FC93B34EBC91@netapp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/fPU4M3bWnW2wcF9WM-ecf7GhfEc Cc: "rmcat@ietf.org" , Erlendur Karlsson , webmaster@tools.ietf.org Subject: Re: [rmcat] Pdf document formatting problems X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:52:40 -0000 * Quoting Eggert, Lars [13 Mar-14 13:01]: > Are you printing them or viewing them on screen? > > If the former, I suspect a page size issue. I became very curious of a PDF document that would *reformat* in different viewers (xpdf showed blank pages, but chrome was OK). However, the discrepancy is caused by a stale web cache: $ wget 'http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf' Connecting to tools.ietf.org (tools.ietf.org)|77.72.230.30|:80... Length: 76566 (75K) [application/pdf] ### wait for it... $ wget 'http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf' Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:80... Length: 91706 (90K) [application/pdf] (or you can do a couple of shift-reload in Chrome) The PDF served from 77.72.230.30 has bad formatting, but the PDF from 64.170.98.42 is fine. As indicated above, they have different sizes and are also created on different days: $ pdfinfo draft-sarker-rmcat-eval-test-00.pdf | grep Creation CreationDate: Thu Feb 20 02:21:32 2014 $ pdfinfo draft-sarker-rmcat-eval-test-00.pdf.1 | grep Creation CreationDate: Wed Feb 19 13:38:50 2014 I'm CCing the tools-webmaster so they can investigate. /Stefan -- Stefan Alfredsson, PhD Tel: +46 (0) 54 700 1668 Datavetenskap Kontor: 21F-425 (Hus Vanern) Karlstads universitet PGP 0xB19B4B16 SE-651 88 Karlstad http://www.cs.kau.se/stefalfr/ From nobody Thu Mar 13 21:00:06 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE0A1A0888 for ; Thu, 13 Mar 2014 21:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Xkgr-gY8rXUX for ; Thu, 13 Mar 2014 21:00:01 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 610FD1A07C9 for ; Thu, 13 Mar 2014 21:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3305; q=dns/txt; s=iport; t=1394769595; x=1395979195; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/0r7WLtG6bR0gq4ttqMHwNNofJYasWEYeFi+sLDMzb8=; b=D0surflK2lgzA6+Adn4+A98KBApvAho1YKLklb7795qIwhCLLIXGMwxH 8kmEfMRQCL3JvKt1rzBk116bbl4h9dJXYbvDOEOloIys1Yhk6IIWZDje3 a1mGgOcqjQtpynI2gcpGiRQR1qsSf7eYweANGvvK2BdaInS6F89sBKg/l 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAF5+IlOtJV2b/2dsb2JhbABZgmUhO1EGwWyBGhZ0giUBAQEEOjQJEgIBCBEBAwEBCxQQMhcEAQEFAwIEEwgBh3ABBwXTfReONDiDJIEUBJl3kHyDLYIr X-IronPort-AV: E=Sophos;i="4.97,651,1389744000"; d="scan'208";a="27400797" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 14 Mar 2014 03:59:54 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2E3xsIJ005400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Mar 2014 03:59:54 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 22:59:54 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "rmcat@ietf.org" Thread-Topic: New Version Notification for draft-zhu-rmcat-nada-03.txt Thread-Index: AQHPPzgS7ErTjPdW6UCyPg9LAX1xDZrf8xt+ Date: Fri, 14 Mar 2014 03:59:53 +0000 Message-ID: References: <20140314034709.26904.15086.idtracker@ietfa.amsl.com> In-Reply-To: <20140314034709.26904.15086.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.10.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/u11vST_-G2DDLQ4WHx8N7wKAEfE Subject: [rmcat] FW: New Version Notification for draft-zhu-rmcat-nada-03.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 04:00:04 -0000 Hi:=0A= =0A= The main changes in this version are as follows:=0A= =0A= a) Added Sec 5.4 to discuss some of the issue related to using different f= orms of delay as congestion indication. Current implementation of NADA reli= es on absolute one-way delay (OWD), but that's only reliable in controlled = environments between senders and receivers with well-synchronized clocks. I= n this section, we also discuss alternative delay signals NADA can use (rel= ative OWD or RTT), and the pros and cons of each approach. Thanks to earli= er discussions with Pal and Michael W on the mailing list for raising this = issue.=0A= =0A= b) Fixed various typos in notations in Sec 3 (System Model) so that they no= w match to the system diagrams and later descriptions in Sec 6 (Sender Beha= vior). =0A= =0A= c) Slightly revise the text in Sec 8 (Implementation Status) to reflect the= fact that we've obtained first set of testbed evaluation results (not too = interesting yet, stay tuned ...)=0A= =0A= As always, comments are welcome. =0A= =0A= Thanks,=0A= Xiaoqing=0A= =0A= ________________________________________=0A= From: internet-drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Thursday, March 13, 2014 10:47 PM=0A= To: Rong Pan (ropan); Xiaoqing Zhu (xiaoqzhu); Rong Pan (ropan); Xiaoqing Z= hu (xiaoqzhu)=0A= Subject: New Version Notification for draft-zhu-rmcat-nada-03.txt=0A= =0A= A new version of I-D, draft-zhu-rmcat-nada-03.txt=0A= has been successfully submitted by Xiaoqing Zhu and posted to the=0A= IETF repository.=0A= =0A= Name: draft-zhu-rmcat-nada=0A= Revision: 03=0A= Title: NADA: A Unified Congestion Control Scheme for Real-Time Med= ia=0A= Document date: 2014-03-13=0A= Group: Individual Submission=0A= Pages: 13=0A= URL: http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-03= .txt=0A= Status: https://datatracker.ietf.org/doc/draft-zhu-rmcat-nada/=0A= Htmlized: http://tools.ietf.org/html/draft-zhu-rmcat-nada-03=0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhu-rmcat-nada-03= =0A= =0A= Abstract:=0A= This document describes a scheme named network-assisted dynamic=0A= adaptation (NADA), a novel congestion control approach for=0A= interactive real-time media applications, such as video conferencing.=0A= In the proposed scheme, the sender regulates its sending rate based=0A= on either implicit or explicit congestion signaling, in a unified=0A= approach. The scheme can benefit from explicit congestion=0A= notification (ECN) markings from network nodes. It also maintains=0A= consistent sender behavior in the absence of such markings, by=0A= reacting to queuing delays and packet losses instead.=0A= =0A= We present here the overall system architecture, recommended=0A= behaviors at the sender and the receiver, as well as expected network=0A= node operations. Results from extensive simulation studies of the=0A= proposed scheme are available upon request.=0A= =0A= =0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= The IETF Secretariat=0A= =0A= From nobody Fri Mar 14 02:30:42 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F261A00AF for ; Fri, 14 Mar 2014 01:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 XIA9Oml-Nmv1 for ; Fri, 14 Mar 2014 01:43:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 361801A00B2 for ; Fri, 14 Mar 2014 01:43:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:58354 helo=vigonier.tools.ietf.org ident=henrik) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WONhp-0001ow-9f; Fri, 14 Mar 2014 09:43:05 +0100 Message-ID: <5322C119.9050408@levkowetz.com> Date: Fri, 14 Mar 2014 09:43:05 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stefan Alfredsson , "Eggert, Lars" References: <4B3BB9C48C026A4FB51BC0E792555962185888@ESESSMB109.ericsson.se> <4B3BB9C48C026A4FB51BC0E79255596218599C@ESESSMB109.ericsson.se> <36CB1835-ABEC-4384-87F6-FC93B34EBC91@netapp.com> <20140313165228.GA16344@sa-pc.cs.kau.se> In-Reply-To: <20140313165228.GA16344@sa-pc.cs.kau.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Stefan.Alfredsson@kau.se, lars@netapp.com, erlendur.karlsson@ericsson.com, rmcat@ietf.org, webmaster@tools.ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/dyVsf9G1vvwAL8ssWLtTGQau6j8 X-Mailman-Approved-At: Fri, 14 Mar 2014 02:30:40 -0700 Cc: "rmcat@ietf.org" , Erlendur Karlsson , webmaster@tools.ietf.org Subject: Re: [rmcat] Pdf document formatting problems X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 08:43:19 -0000 On 2014-03-13 17:52 Stefan Alfredsson said the following: > * Quoting Eggert, Lars [13 Mar-14 13:01]: >> Are you printing them or viewing them on screen? >> >> If the former, I suspect a page size issue. > > I became very curious of a PDF document that would *reformat* > in different viewers (xpdf showed blank pages, but chrome was OK). > > However, the discrepancy is caused by a stale web cache: > > $ wget 'http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf' > Connecting to tools.ietf.org (tools.ietf.org)|77.72.230.30|:80... > Length: 76566 (75K) [application/pdf] > > ### wait for it... > > $ wget 'http://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-00.pdf' > Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:80... > Length: 91706 (90K) [application/pdf] > > > (or you can do a couple of shift-reload in Chrome) > > > The PDF served from 77.72.230.30 has bad formatting, > but the PDF from 64.170.98.42 is fine. > As indicated above, they have different sizes and are > also created on different days: > > $ pdfinfo draft-sarker-rmcat-eval-test-00.pdf | grep Creation > CreationDate: Thu Feb 20 02:21:32 2014 > > $ pdfinfo draft-sarker-rmcat-eval-test-00.pdf.1 | grep Creation > CreationDate: Wed Feb 19 13:38:50 2014 > > I'm CCing the tools-webmaster so they can investigate. The issue should be fixed now. The underlying issue with the flawed generation was fixed already about a month ago, but I'd neglected to clean out the cached files on at least one of the tools servers. Thanks for the analysis and alert! Best regards, Henrik From nobody Fri Mar 14 05:39:28 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2E1A011F for ; Fri, 14 Mar 2014 05:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 nwuYKUb1--ys for ; Fri, 14 Mar 2014 05:39:16 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 989151A0145 for ; Fri, 14 Mar 2014 05:39:10 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so2062462wgg.13 for ; Fri, 14 Mar 2014 05:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CssM/xp5SZXStEsBt0yaNwFnx+pWTyrGcD9hqJ9wjPU=; b=yxdF7VonU6THazNZJqpGdY2j4XZbrezpsfidsHKYXl13nXIY4mYxBOuvSwyfdX12Ks KCYOeK5aCc5Ev6ek9x0C0m9+iuOR2Sy9fi2aJlBmiU09+Zh6GoZovjmYzzzomWNOxa6i EzQ+piXV+djZfntuJyp6+8EOjuK76zXMx5KoNqb3WhPg5FIkL3XmEl7CRFJDP0VknHKM ZFMUwI0vPuE55Lpdex/7/anGYThV6YB8Vop6ITBxYysjF8Xq9Vut6NrYitSpWCToGaD3 ZidLlGhjAzkkx+azhxF5PfRGlj2DtA9rhD175BT4hJkSsaK1HqmtZqNkv/MxbBeENlOK LC+g== MIME-Version: 1.0 X-Received: by 10.194.6.106 with SMTP id z10mr6255970wjz.1.1394800743423; Fri, 14 Mar 2014 05:39:03 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Fri, 14 Mar 2014 05:39:03 -0700 (PDT) Date: Fri, 14 Mar 2014 05:39:03 -0700 Message-ID: From: Dave Taht To: webrtc@googlecode.com, "rmcat@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/_TCLkEsJ0CzyotMM3-KACBIUqUw Subject: [rmcat] ECN marking for webrtc and stun packets? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 12:39:20 -0000 I am curious if anyone has outlined an approach to CC for webrtc (rtp, stun, etc) based on more fully utilizing ECN for it? The only thing that I see that sort of touches upon it was this: http://www.tschofenig.priv.at/cc-workshop/draft-arkko-wscc-deployment-00.tx= t --=20 Dave T=E4ht From nobody Fri Mar 14 05:56:20 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C651A0140 for ; Fri, 14 Mar 2014 05:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JL6z2BB40o1h for ; Fri, 14 Mar 2014 05:56:14 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1AE1A013F for ; Fri, 14 Mar 2014 05:56:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,654,1389772800"; d="asc'?scan'208";a="109276449" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 14 Mar 2014 05:56:07 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 05:56:07 -0700 From: "Eggert, Lars" To: Dave Taht Thread-Topic: [rmcat] ECN marking for webrtc and stun packets? Thread-Index: AQHPP4J2o8LyYAjs90e4zAVX+CPl7prg/9oA Date: Fri, 14 Mar 2014 12:56:06 +0000 Message-ID: <5471F694-48F8-40FF-B1EA-716140862151@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] Content-Type: multipart/signed; boundary="Apple-Mail=_FBCACC58-AB05-4BF6-BB55-3A2F3189388B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/uUyblWrmg4aZURUiLiMzXEkQn3g Cc: "rmcat@ietf.org" , "webrtc@googlecode.com" Subject: Re: [rmcat] ECN marking for webrtc and stun packets? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 12:56:16 -0000 --Apple-Mail=_FBCACC58-AB05-4BF6-BB55-3A2F3189388B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, there is also RFC6679, which deals with RTP but not (necessarily) in the = context of webrtc. Lars On 2014-3-14, at 13:39, Dave Taht wrote: > I am curious if anyone has outlined an approach to CC for > webrtc (rtp, stun, etc) based on more fully utilizing ECN for > it? >=20 > The only thing that I see that sort of touches upon it was this: >=20 > = http://www.tschofenig.priv.at/cc-workshop/draft-arkko-wscc-deployment-00.t= xt >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 --Apple-Mail=_FBCACC58-AB05-4BF6-BB55-3A2F3189388B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUyL8ZtZcnpRveo1xAQJ/kwQAjhmY2IHfQ1tgcWnDY8RuOCtL61abeE4f frLZzk9NaMkIi73zGoC3Mc2kJA10JMYID5hOnJEeyZMBPD2YAa2jAvc37lmXn/g4 p9knLoWrFVOgKuAc+e42XOOWjwFOZAY5YeLp7uSP9FWhVRyNnUPYxRm4+HwTxtf8 AMIBCI+noU4= =e4M1 -----END PGP SIGNATURE----- --Apple-Mail=_FBCACC58-AB05-4BF6-BB55-3A2F3189388B-- From nobody Fri Mar 14 06:02:52 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47E61A013B for ; Fri, 14 Mar 2014 06:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 UDJVSTk0Kyng for ; Fri, 14 Mar 2014 06:02:48 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 486ED1A0117 for ; Fri, 14 Mar 2014 06:02:48 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WORl2-00049d-FC; Fri, 14 Mar 2014 14:02:40 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WORl2-0004Pe-1e; Fri, 14 Mar 2014 14:02:40 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_425907C2-1515-4557-B525-BD8B8B8657C8" From: Michael Welzl In-Reply-To: <5471F694-48F8-40FF-B1EA-716140862151@netapp.com> Date: Fri, 14 Mar 2014 14:02:39 +0100 Message-Id: <7B0A4841-56EC-4A0B-A14D-32EAE4D70C5C@ifi.uio.no> References: <5471F694-48F8-40FF-B1EA-716140862151@netapp.com> To: rmcat WG X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 3 total rcpts 13603 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EBEF29C535B205799492BA249936F45DD795ECF1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 4604 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/9S6Bztd4upNK2QkXZHnbn66jP1g Cc: webrtc@googlecode.com Subject: Re: [rmcat] ECN marking for webrtc and stun packets? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:02:50 -0000 --Apple-Mail=_425907C2-1515-4557-B525-BD8B8B8657C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 ... and NADA quite explicitly incorporates ECN: http://tools.ietf.org/html/draft-zhu-rmcat-nada-03 Cheers, Michael On 14. mars 2014, at 13:56, Eggert, Lars wrote: > Hi, >=20 > there is also RFC6679, which deals with RTP but not (necessarily) in = the context of webrtc. >=20 > Lars >=20 > On 2014-3-14, at 13:39, Dave Taht wrote: >=20 >> I am curious if anyone has outlined an approach to CC for >> webrtc (rtp, stun, etc) based on more fully utilizing ECN for >> it? >>=20 >> The only thing that I see that sort of touches upon it was this: >>=20 >> = http://www.tschofenig.priv.at/cc-workshop/draft-arkko-wscc-deployment-00.t= xt >>=20 >>=20 >>=20 >> --=20 >> Dave T=E4ht >>=20 >=20 --Apple-Mail=_425907C2-1515-4557-B525-BD8B8B8657C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ... = and NADA quite explicitly incorporates ECN:

Cheers,<= /div>
Michael


On 14. mars = 2014, at 13:56, Eggert, Lars wrote:

Hi,

there is also RFC6679, which deals with = RTP but not (necessarily) in the context of = webrtc.

Lars

On 2014-3-14, at 13:39, Dave Taht <dave.taht@gmail.com> = wrote:

I am curious if anyone has = outlined an approach to CC for
webrtc (rtp, stun, etc) based on more fully utilizing ECN = for
it?

The only thing = that I see that sort of touches upon it was = this:

http://www.tschofenig.priv.at/cc-workshop/draft-arkko-wscc-dep= loyment-00.txt



-- =
Dave = T=E4ht



= --Apple-Mail=_425907C2-1515-4557-B525-BD8B8B8657C8-- From nobody Fri Mar 14 06:10:05 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225AB1A013B for ; Fri, 14 Mar 2014 06:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 s7pCcEeeFvW4 for ; Fri, 14 Mar 2014 06:09:59 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id F32071A0133 for ; Fri, 14 Mar 2014 06:09:58 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so2557390wib.4 for ; Fri, 14 Mar 2014 06:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fQhZjvUQfJIbny7KPRIm99EFhDGjHLIxpTmHXaGjrvQ=; b=htNv11FdA5JgRcvA6FW/UqsEzO2kNIaUVmgtu8eHnl7d08S9pq84QE6/b0ovH+A+YK Bq2Msvo6u3SYj1Y32OlQ8dHp14BZ/VHg9cLjX5K+j+Bi/bI5audUyXom6rnk6Yd21zAX 7UD4D2Vb881HeG0Wx+FaVcogDPKYj71yfNCWsGUYHBoAyPrzaVbwv14quu5b5W2zjsI8 MVUXbmyEfy/Jx5TuI6rEoeErV9aRi2A1cAD1xHzCokxkzxq3A5Vjox9eX5Eci6VxsHqW X/R7A28wLIiAkOtUzF3SHGrBJ86Ud2XhB/3bKxGCRnrPqBSNcv8sBco9ws07vVYk7Kj5 7kgw== MIME-Version: 1.0 X-Received: by 10.194.6.106 with SMTP id z10mr6383180wjz.1.1394802591511; Fri, 14 Mar 2014 06:09:51 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Fri, 14 Mar 2014 06:09:51 -0700 (PDT) In-Reply-To: <7B0A4841-56EC-4A0B-A14D-32EAE4D70C5C@ifi.uio.no> References: <5471F694-48F8-40FF-B1EA-716140862151@netapp.com> <7B0A4841-56EC-4A0B-A14D-32EAE4D70C5C@ifi.uio.no> Date: Fri, 14 Mar 2014 06:09:51 -0700 Message-ID: From: Dave Taht To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/geUNBtynoG_3KiFlUz4e31LXRak Cc: rmcat WG , webrtc@googlecode.com Subject: Re: [rmcat] ECN marking for webrtc and stun packets? X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:10:01 -0000 On Fri, Mar 14, 2014 at 6:02 AM, Michael Welzl wrote: > ... and NADA quite explicitly incorporates ECN: > http://tools.ietf.org/html/draft-zhu-rmcat-nada-03 > > Cheers, > Michael I obviously did not google hard enough. Thank you both. (This is in reaction to the ongoing thread on using extensive QoS markings in stun with the implied assumption that using AFxx would actually accomplish anything on common media types like wifi) It does not appear if nada has made it as far as the webrtc sources. > > On 14. mars 2014, at 13:56, Eggert, Lars wrote: > > Hi, > > there is also RFC6679, which deals with RTP but not (necessarily) in the > context of webrtc. > > Lars > > On 2014-3-14, at 13:39, Dave Taht wrote: > > I am curious if anyone has outlined an approach to CC for > > webrtc (rtp, stun, etc) based on more fully utilizing ECN for > > it? > > > The only thing that I see that sort of touches upon it was this: > > > http://www.tschofenig.priv.at/cc-workshop/draft-arkko-wscc-deployment-00.= txt > > > > > -- > > Dave T=E4ht > > > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Thu Mar 20 07:58:57 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905DD1A074E for ; Thu, 20 Mar 2014 07:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 Nh_b-Cmd0VP2 for ; Thu, 20 Mar 2014 07:58:52 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 122C01A03FE for ; Thu, 20 Mar 2014 07:58:52 -0700 (PDT) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4401 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQeQc-0003Nm-RL for rmcat@ietf.org; Thu, 20 Mar 2014 09:58:42 -0500 Message-ID: <532B0222.7070503@jesup.org> Date: Thu, 20 Mar 2014 10:58:42 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <531CC124.3000209@alvestrand.no> <201403121457.51984.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201403121457.51984.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/DK3xTsK6O_67dVRHjlJzD35nqU0 Subject: Re: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-requirements-02) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 14:58:53 -0000 On 3/12/2014 9:57 AM, Mirja Kühlewind wrote: > Hi (as individual contributor), > > I'd think RTT-fairness is in general a good thing. The question would be, is > there in rmcat an requirement for RTT-fairness that is more important than > for other kinds of traffic? I'd actually say yes, because the quality of my > call should not depend on the fact that my communication partner sits next > door or on a different continent. (I know it still might, but hopefully not > because of a RTT-fairness issue...). > > That's for me the reason why this could/should be listed explicitly in the > requirement document. Like actually all requirements, RTT-fairness should > only be a 'should', thus it will not be the doorkeeper to not except a > candidate. But that's similar for all requirements. We might not be able to > find a solution that can always fulfill all requirement, thus at the end we > need to have a discussion which requirements are okay to break. > 100% agree: it can be a goal we include in evaluation, but not a hard blocker -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Thu Mar 20 08:13:22 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339ED1A06D2 for ; Thu, 20 Mar 2014 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 zfKxj3gt63EM for ; Thu, 20 Mar 2014 08:13:17 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06F1A069C for ; Thu, 20 Mar 2014 08:13:17 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WQeeZ-0003rf-G8; Thu, 20 Mar 2014 16:13:07 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WQeeZ-0004co-49; Thu, 20 Mar 2014 16:13:07 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <532B0222.7070503@jesup.org> Date: Thu, 20 Mar 2014 16:13:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D8C1ABA-DBCC-41C4-A29E-FDFDA3B8FA34@ifi.uio.no> References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <531CC124.3000209@alvestrand.no> <201403121457.51984.mirja.kuehlewind@ikr.uni-stuttgart.de> <532B0222.7070503@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 6 sum msgs/h 4 total rcpts 13884 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0A934B983FD29491373E919221257BC7D1978782 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 4715 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/PqDZeRZW1FLphMKhNVw7dcKJ3-4 Cc: rmcat@ietf.org Subject: Re: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-requirements-02) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 15:13:20 -0000 On 20. mars 2014, at 15:58, Randell Jesup wrote: > On 3/12/2014 9:57 AM, Mirja K=FChlewind wrote: >> Hi (as individual contributor), >>=20 >> I'd think RTT-fairness is in general a good thing. The question would = be, is >> there in rmcat an requirement for RTT-fairness that is more important = than >> for other kinds of traffic? I'd actually say yes, because the quality = of my >> call should not depend on the fact that my communication partner sits = next >> door or on a different continent. (I know it still might, but = hopefully not >> because of a RTT-fairness issue...). >>=20 >> That's for me the reason why this could/should be listed explicitly = in the >> requirement document. Like actually all requirements, RTT-fairness = should >> only be a 'should', thus it will not be the doorkeeper to not except = a >> candidate. But that's similar for all requirements. We might not be = able to >> find a solution that can always fulfill all requirement, thus at the = end we >> need to have a discussion which requirements are okay to break. >>=20 >=20 > 100% agree: it can be a goal we include in evaluation, but not a hard = blocker Fine by me. (and for those who totally want it, coupled cc. should be able to force = it onto the controller anyway, at least for the flows that originate = from one host) From nobody Mon Mar 31 06:12:24 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8A61A0851 for ; Mon, 31 Mar 2014 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YeOVcBxi6_i9 for ; Mon, 31 Mar 2014 06:12:19 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4511A086B for ; Mon, 31 Mar 2014 06:12:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,765,1389772800"; d="asc'?scan'208";a="113492430" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 31 Mar 2014 06:12:16 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.49]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 06:12:15 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 Thread-Index: AQHPK+/5W0yOYNlYsEiKSPgfn46BpJr74yAA Date: Mon, 31 Mar 2014 13:12:14 +0000 Message-ID: References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> In-Reply-To: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.29] Content-Type: multipart/signed; boundary="Apple-Mail=_BBCF7BEB-0A89-451E-8568-9898052622E4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/mByMWJtjGANUU0PwSKvZnOnkfeQ Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:12:20 -0000 --Apple-Mail=_BBCF7BEB-0A89-451E-8568-9898052622E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-2-17, at 15:53, Eggert, Lars wrote: > we'd like to start the working group last call for = draft-ietf-rmcat-cc-requirements-02. Please send your feedback to the = list. >=20 > We're letting this LC run until March 12 (after the London meeting), = so there will also be a chance to discuss any feedback there. the WGLC has concluded. Thank you all for commenting; we are expecting = the editor to submit a version reflecting them shortly. Afterwards, we = will forward the document to the IESG. Lars --Apple-Mail=_BBCF7BEB-0A89-451E-8568-9898052622E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUzlprNZcnpRveo1xAQKI3AP+IaYgIBM+axPWgoWd5LHwhy4Nm67OrfFU euy2OOQGmQwDskCIXCoNNQR+uk7iaafSIAHRIML6wY1wfHQ4c8THyb4uPMKinUnY 8Y1M7sR4AbQMj2KucjxVop8WdegE/WGYdJNIb86CEY7iJL8svA9za7H09JdEhydE hX0Bej71bH8= =XpSn -----END PGP SIGNATURE----- --Apple-Mail=_BBCF7BEB-0A89-451E-8568-9898052622E4-- From nobody Mon Mar 31 06:36:44 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3CE1A0867 for ; Mon, 31 Mar 2014 06:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 n2u_ArkTISIp for ; Mon, 31 Mar 2014 06:36:39 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D20231A0860 for ; Mon, 31 Mar 2014 06:36:38 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5A84E6027D; Mon, 31 Mar 2014 15:36:34 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 57B1F6027C; Mon, 31 Mar 2014 15:36:34 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Mon, 31 Mar 2014 15:36:34 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201403311536.34255.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/yn0ez5pJEOu4koEmbB9ysuH8l1Q Cc: "Karen E. Egede Nielsen" , "Eggert, Lars" Subject: [rmcat] Test Cases for Evaluation X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:36:41 -0000 Hi group, we would like to know who has read the document(s) that are specifying evaluation test cases, especially draft-sarker-rmcat-eval-test-00, and if those people think the content of the document(s) is interesting for the working group and that the group should continue to work on this (which means potentially adding a milestone)? Thanks, Mirja From nobody Mon Mar 31 07:03:06 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3B31A0A3F for ; Mon, 31 Mar 2014 07:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.14 X-Spam-Level: X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 IKPQYcTGqX7L for ; Mon, 31 Mar 2014 07:02:52 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id C54851A0A24 for ; Mon, 31 Mar 2014 07:02:52 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 61AED6028A; Mon, 31 Mar 2014 16:02:49 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5E8A260274; Mon, 31 Mar 2014 16:02:49 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Mon, 31 Mar 2014 16:02:49 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/tj0LN90I4ycCL2usbGg70V1CTEA Cc: "Karen E. Egede Nielsen" , jo@comnet.tkk.fi, "Eggert, Lars" , Varun Singh Subject: [rmcat] Please review draft-ietf-rmcat-eval-criteria-01 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:02:58 -0000 Hi group, draft-ietf-rmcat-eval-criteria-01 was updated after the last meeting addressing all comments from the meeting. We would really need people to review this document now! Please do so! https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ Mirja From nobody Mon Mar 31 08:52:05 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A541A6F52 for ; Mon, 31 Mar 2014 08:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.175 X-Spam-Level: * X-Spam-Status: No, score=1.175 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_XBL=0.375] 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 Bjn1nES4dQ5i for ; Mon, 31 Mar 2014 08:51:59 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C9A4E1A6F49 for ; Mon, 31 Mar 2014 08:51:59 -0700 (PDT) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:3926 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUeVA-000FBB-Dz for rmcat@ietf.org; Mon, 31 Mar 2014 10:51:56 -0500 Message-ID: <53398F08.2060602@jesup.org> Date: Mon, 31 Mar 2014 11:51:36 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com> <5314D7D9.1080703@ericsson.com> In-Reply-To: <5314D7D9.1080703@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/6-7GKTQMXA-jInjGCDuZPv3oy8I Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:52:01 -0000 Planning an update incorporating feedback later today. Incorporated feedback from Magnus. Three notes: On 3/3/2014 2:28 PM, Magnus Westerlund wrote: > 4. Section 2, Req 1.D: > > Similarly periodic bursty flows such as DASH or proprietary > > I would suggest adding a reference to DASH and possibly expand it. Done, though I had to guess at the correct way to reference an ISO spec. > 9. Section 2, Req 6.A > > A. In WebRTC, a division of packets into 4 classes is > envisioned in order of priority: faster-than-audio, audio, > video, best-effort, and bulk-transfer. Typically the flows > managed by this algorithm would be audio or video in that > heirarchy, and feedback flows would be faster-than-audio. > > This doesn't match what is currently in > draft-dhesikan-tsvwg-rtcweb-qos-05. I wonder if this needs to be > either generalized or reference this document? The division I mention was spoken to (can't remember if it was on-list, or in a meeting) in the terms I gave above. To be honest, I'd want something equivalent to that, and if the draft given isn't providing it yet we need to address that. I'd want feedback data to have higher priority than audio if at all possible; if not higher then equal to audio. This is complicated by there being no standard ordering of DSCP classes. Thus far I'm not referencing that personal draft. And "envisioned" is a very soft term. > > 10. Section 2. > > Another requirement that might be missing and is related to 6.A, but > not the same. It is the possibility to indicate the relative priority > between multiple streams in the same session context. This doesn't > require any QoS, just that the sending application indicates relative > priority and that affects how bit-rate gets distributed. Or has the > discussion been that it will be the higher layers that do this > re-distribution between streams for which one have indication if they > can increase or reduce the stream. > Yes, if there's a shared congestion context with multiple streams, then something is deciding how many bits of the shared resource each stream gets, and that's not part of this requirement. I'd consider how the bits are apportioned between flows in a coupled-cc case as not being part of this requirement. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Mar 31 10:38:41 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733601A6F3F for ; Mon, 31 Mar 2014 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 tq6bUDbXBVJy for ; Mon, 31 Mar 2014 10:38:33 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9248E1A6F42 for ; Mon, 31 Mar 2014 10:38:33 -0700 (PDT) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4253 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUgAI-000AHK-AQ for rmcat@ietf.org; Mon, 31 Mar 2014 12:38:30 -0500 Message-ID: <5339A802.8090602@jesup.org> Date: Mon, 31 Mar 2014 13:38:10 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3B7006B2-C2A5-472B-BC74-15BD2F4D0208@netapp.com>, <6EDFD6CF-D260-4D15-9844-F50299F593B5@ifi.uio.no>, <5315F511.1060505@jesup.org>, <42D6008D-C8ED-4EB1-81D6-A9FECDD2C368@ifi.uio.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050304060309080300070009" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/hO9HtiswvTHsyCeoLtjKRAiAOWM Subject: Re: [rmcat] Review of draft-ietf-rmcat-cc-requirements-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:38:37 -0000 This is a multi-part message in MIME format. --------------050304060309080300070009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/4/2014 11:26 AM, Bernard Aboba wrote: > Here are my comments on the document. > > 1. The congestion control algorithm must attempt to provide as-low- > as-possible-delay transit for real-time traffic while still > providing a useful amount of bandwidth, even when faced with > intermediate bottlenecks and competing flows. > [BA] I am not sure that this requirement is meaningful because of the potential influence of the competing flows. For example, when TCP is competing with > realtime traffic, it will tend to fill the queue to the point of inducing > loss, and there is not much that the RMCAT algorithm can do about this - the "attempts" will be in vain. SoI would separate the requirement into multiple parts, one stating goals inthe absence of competing traffic, and another part talking about goals in the presence of competing flows. I separated that out into a bullet point, and mentioned there's a limit on what's possible to achieve. > > There may be > lower limits on the amount of bandwidth that is useful, but this > is largely application-specific and the application may be able > to modify or remove flows in order allow some useful flows to > get enough bandwidth. > [BA] There are situations such as scalable video coding where the "lower > limit" is not application-specific, because it relates to the characteristics of the base layer. So in these situations, once you have stopped sending > extension layers, you only have the base layer, whose characteristics may > not be flexible because of the relationship between the base and extension > layers. I don't see this as affecting the requirement; we state there may be lower limits, and that this is "largely" application-specific (and "application-specific" would include a layered codec and the configuration of that codec). > A. It should also handle routing changes and interface changes > (WiFi to 3G data, etc) which may radically change the > bandwidth available, and react quickly, especially if there > is a reduction in available bandwidth. > [BA] We need to separate routing and interface changes, because routing > changes are typically invisible to the application, whereas interface > changes will not be. I would argue that reacting "quickly" to routing > transients is a non-goal because this is a regular feature of the Internet, > and the major requirement is to be resilient against them. This is one > of the reasons that Circuit Breakers is likely to be ineffective in practice- shutting down communications and requiring manual intervention in > response to a routing transient is going to be annoying at best. > Interface changes are a distinct issue, because information could be > provided (either through use of bw estimates or information relating > to the interface itself) that could help reset the parameters of the > video encoder shortly after the interface change. Separated them, and also mentioned that on an interface change we assume the algorithm can be notified. > C. The algorithm must not overreact to short-term bursts (such > as web-browsing) which can quickly saturate a local- > bottleneck router or link, but also clear quickly, and > should recover quickly when the burst ends. This is > inherently at odds with the need to react quickly-enough to > avoid queue buildup. > [BA] It is also at odds with the ability to react quickly to rate adaptation on wireless networks. Among other things. We like things that are inherently at odds in low-delay congestion control ;-) :-/ > D. Similarly periodic bursty flows such as DASH or proprietary > media streaming algorithms may compete in bursts with the > algorithm, and may not be adaptive within a burst. They are > often are layered on top of TCP. The algorithm must avoid > too much delay buildup during those bursts, and quickly > recover. Note that this traffic may on an access link, or > may cause a shift in the location of the bottleneck fir the > duration of the burst. > [BA] I would argue that it is not within the power of the algorithm to avoid > delay buildup due to competing flows. They are what they are. The only > thing RMCAT can do is to decide how it wishes to behave in response. I disagree in detail, though I agree in general. Our algorithm will affect other protocols, if in no other way than how quickly they ramp up and exactly where they stabilize. Since these are time-limited, we may have some luck in allowing moderate delay buildup during a burst, or perhaps simply giving in for the burst and immediately popping back up after it ends will work better. (Especially if the algorithm can detect a regular bursty flow or simply the end of a competing flow.) For example, we could notice a sudden very-greedy flow, back way off, and as soon as we see the queue start to drain immediately try restoring our previous flow level instead of ramping back up. If we immediately start building queues, we know it wasn't a simple burst and can switch behaviors. So I'll keep the current text and let's see what the proposals can manage. > A. If possible, it should also share information and adaptation > with other non-RTP flows between the same endpoints, such as > a WebRTC data channel > [BA] Cooperative adaptation between RTP and SCTP is a tall order, particularly since the RMCAT WG is not chartered to work on SCTP congestion control. "If possible." This might occur at the application or congestion-controller level. > 11. It should be evaluated in how it works both with backbone-router > bottlenecks, (asymmetric) local-loop bottlenecks, and local-lan > (WiFi/etc) bottlenecks, and in competition with varying numbers > and types of streams (TCP, TCP variants in use, LEDBAT > [I-D.ietf-ledbat-congestion ], inflexible VoIP UDP flows). > [BA] WiFi, with its (often broken) rate adaptation is going to be a specialchallengefor evaluation, because the loss could be due to interference or poor rate adaptation, rather than due > to congestion. I would probably delete this. > it should be evaluated with regards to those. This is for the evaluation spec. And some of those evaluations may be more useful than others, or easier than others. WiFi may be problematic, but it's a HUGE usecase, and larger going forward. In terms of importance, I'd likely put it on a par with wired and perhaps even higher (thinking to the future). Of course, it may work better with newer/better/less-buggy wifi routing too. -- Randell Jesup -- rjesup a t mozilla d o t com --------------050304060309080300070009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/4/2014 11:26 AM, Bernard Aboba wrote:
Here are my comments on the document.

   1.   The congestion control algorithm must attempt to provide as-low-
        as-possible-delay transit for real-time traffic while still
        providing a useful amount of bandwidth, even when faced with
        intermediate bottlenecks and competing flows.

          
[BA] I am not sure that this requirement is meaningful because of the potential influence of the competing flows.  For example, when TCP is competing with

          
realtime traffic, it will tend to fill the queue to the point of inducing

          
loss, and there is not much that the RMCAT algorithm can do about this - the "attempts" will be in vain.  So I would separate the requirement into multiple parts, one stating goals in the absence of competing traffic, and another part talking about goals in the presence of competing flows. 

        

      

    

    

    I separated that out into a bullet point, and mentioned there's a
    limit on what's possible to achieve.

    

    

      

        

          



          
        There may be
        lower limits on the amount of bandwidth that is useful, but this
        is largely application-specific and the application may be able
        to modify or remove flows in order allow some useful flows to
        get enough bandwidth. 

          

          
[BA] There are situations such as scalable video coding where the "lower

          
limit" is not application-specific, because it relates to the characteristics of the base layer.  So in these situations, once you have stopped sending

          
extension layers, you only have the base layer, whose characteristics may

          
not be flexible because of the relationship between the base and extension

          
layers. 

        

      

    

    

    I don't see this as affecting the requirement; we state there may be
    lower limits, and that this is "largely" application-specific (and
    "application-specific" would include a layered codec and the
    configuration of that codec).

    

    

      

        

          

          
        A.  It should also handle routing changes and interface changes
            (WiFi to 3G data, etc) which may radically change the
            bandwidth available, and react quickly, especially if there
            is a reduction in available bandwidth.

          

          
[BA] We need to separate routing and interface changes, because routing

          
changes are typically invisible to the application, whereas interface

          
changes will not be.  I would argue that reacting "quickly" to routing

          
transients is a non-goal because this is a regular feature of the Internet,

          
and the major requirement is to be resilient against them.   This is one

          
of the reasons that Circuit Breakers is likely to be ineffective in practice- shutting down communications and requiring manual intervention in

          
response to a routing transient is going to be annoying at best. 

          

          
Interface changes are a distinct issue, because information could be

          
provided (either through use of bw estimates or information relating

          
to the interface itself) that could help reset the parameters of the

          
video encoder shortly after the interface change.  

        

      

    

    

    Separated them, and also mentioned that on an interface change we
    assume the algorithm can be notified.

    

    

      

        

          

          
        C.  The algorithm must not overreact to short-term bursts (such
            as web-browsing) which can quickly saturate a local-
            bottleneck router or link, but also clear quickly, and
            should recover quickly when the burst ends.  This is
            inherently at odds with the need to react quickly-enough to
            avoid queue buildup.

          

          
[BA] It is also at odds with the ability to react quickly to rate adaptation on wireless networks. 

        

      

    

    

    Among other things.  We like things that are inherently at odds in
    low-delay congestion control ;-) :-/

    

    

      

        

          

          
        D.  Similarly periodic bursty flows such as DASH or proprietary
            media streaming algorithms may compete in bursts with the
            algorithm, and may not be adaptive within a burst.  They are
            often are layered on top of TCP.  The algorithm must avoid
            too much delay buildup during those bursts, and quickly
            recover.  Note that this traffic may on an access link, or
            may cause a shift in the location of the bottleneck fir the
            duration of the burst.

          

          
[BA] I would argue that it is not within the power of the algorithm to avoid

          
delay buildup due to competing flows.  They are what they are.  The only

          
thing RMCAT can do is to decide how it wishes to behave in response.

        

      

    

    

    I disagree in detail, though I agree in general.  Our algorithm will
    affect other protocols, if in no other way than how quickly they
    ramp up and exactly where they stabilize.  Since these are
    time-limited, we may have some luck in allowing moderate delay
    buildup during a burst, or perhaps simply giving in for the burst
    and immediately popping back up after it ends will work better. 
    (Especially if the algorithm can detect a regular bursty flow or
    simply the end of a competing flow.)  For example, we could notice a
    sudden very-greedy flow, back way off, and as soon as we see the
    queue start to drain immediately try restoring our previous flow
    level instead of ramping back up.  If we immediately start building
    queues, we know it wasn't a simple burst and can switch behaviors.

    

    So I'll keep the current text and let's see what the proposals can
    manage.

    

    

      

        

          

          
        A.  If possible, it should also share information and adaptation
            with other non-RTP flows between the same endpoints, such as


          
                              a WebRTC data channel 

          

          
[BA] Cooperative adaptation between RTP and SCTP is a tall order, particularly since the RMCAT WG is not chartered to work on SCTP congestion control. 

        

      

    

    

    "If possible."  This might occur at the application or
    congestion-controller level.

    

    

      

        

          

          
   11.  It should be evaluated in how it works both with backbone-router
        bottlenecks, (asymmetric) local-loop bottlenecks, and local-lan
        (WiFi/etc) bottlenecks, and in competition with varying numbers
        and types of streams (TCP, TCP variants in use, LEDBAT
        [I-D.ietf-ledbat-congestion], inflexible VoIP UDP flows).

          

          
[BA] WiFi, with its (often broken) rate adaptation is going to be a specialchallenge for evaluation, because the loss could be due to interference or poor rate adaptation, rather than due

          
to congestion.  I would probably delete this. 

          

        

      

    

    

    it should be evaluated with regards to those.  This is for the
    evaluation spec.  And some of those evaluations may be more useful
    than others, or easier than others.  WiFi may be problematic, but
    it's a HUGE usecase, and larger going forward.  In terms of
    importance, I'd likely put it on a par with wired and perhaps even
    higher (thinking to the future).  Of course, it may work better with
    newer/better/less-buggy wifi routing too.

    

    

    
-- 
Randell Jesup -- rjesup a t mozilla d o t com


  


--------------050304060309080300070009--


From nobody Mon Mar 31 13:52:37 2014
Return-Path: 
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29A1A701F; Mon, 31 Mar 2014 13:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 SLdq2ojTcDod; Mon, 31 Mar 2014 13:52:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CC01A7011; Mon, 31 Mar 2014 13:52:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140331205232.19899.10134.idtracker@ietfa.amsl.com>
Date: Mon, 31 Mar 2014 13:52:32 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/AF1RdRDagflmhZN1CuRs1nkjyOE
Cc: rmcat@ietf.org
Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-03.txt
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 20:52:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF.

        Title           : Congestion Control Requirements For RMCAT
        Author          : Randell Jesup
	Filename        : draft-ietf-rmcat-cc-requirements-03.txt
	Pages           : 9
	Date            : 2014-03-31

Abstract:
   Congestion control is needed for all data transported across the
   Internet, in order to promote fair usage and prevent congestion
   collapse.  The requirements for interactive, point-to-point real time
   multimedia, which needs low-delay, semi-reliable data delivery, are
   different from the requirements for bulk transfer like FTP or bursty
   transfers like Web pages.

   This document attempts to describe a set of requirements that can be
   used to evaluate other congestion control mechanisms in order to
   figure out their fitness for this purpose, and in particular to
   provide a set of possible requirements for proposals coming out of
   the RMCAT Working Group.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/