From zaheduzzaman.sarker@ericsson.com Mon Dec 2 07:22:42 2013 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 3D73C1AE057 for ; Mon, 2 Dec 2013 07:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 JTEuJqpL2J0D for ; Mon, 2 Dec 2013 07:22:40 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACDF1A1F02 for ; Mon, 2 Dec 2013 07:22:39 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-34-529ca5bd0096 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 2D.D2.22496.DB5AC925; Mon, 2 Dec 2013 16:22:37 +0100 (CET) Received: from [150.132.141.79] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Mon, 2 Dec 2013 16:22:36 +0100 Message-ID: <529CA5BC.9000508@ericsson.com> Date: Mon, 2 Dec 2013 16:22:36 +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: , rmcat WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJMWRmVeSWpSXmKPExsUyM+Jvre7epXOCDM51CVmc3ZZlsfrmBzYH Jo8lS34yeXxYvo4tgCmKyyYlNSezLLVI3y6BK2PxhxOsBdM0KqY3T2VsYGxS6GLk5JAQMJGY ufQ+G4QtJnHh3nogm4tDSOAEo8SrNyeZIJzVjBLv7/UyglTxCmhLvOqezg5iswioSCy4+wSo g4ODTcBG4vFiP5Awv4CkxIaG3cwgtqhAlMT5cy+ZIFoFJU7OfMICYosImEsc3HsSrEZYwEzi 9LnLYDXMArYSF+ZcZ4Gw5SWat85mBhkvJKAr0fUybgIj/ywkk2Yh6ZiFpGMBI/MqRsni1OLi 3HQjA73c9NwSvdSizOTi4vw8veLUTYzAEDy45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwLjSYIOvZ98fDmbR1227vz3ZrLBVNpn1kNuVLVrrMmVzTd+Y rohrPrr2tODfVHbjc6mpJw68MZX+LvEje3vxopwVj6Wvfi/gnrz+Q1Xoon/JM3kr34Xl8k6I sC71anpyuMZkb+nrGy2/GndN7T9TEm/05pdZ2Yat1/psNBgz3mXdOH/+14FQIRYlluKMREMt 5qLiRAAXSYZ5DwIAAA== Subject: [rmcat] review of draft-ietf-rmcat-cc-requirements-00 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, 02 Dec 2013 15:22:42 -0000 Hi, I was waiting for -01 version but decided to go against it. I think some of the points I mentioned here were already touched by other reviewers (now you know why I was waiting) but perhaps my version gives a different view. My comments on draft-ietf-rmcat-cc-requirements-00 below- In general this draft lists possible requirements and hints for evaluating congestion control algorithms. However, this draft ends up being a mix of general requirements and design specifications/choices. Sometime it only mentions a requirement as "deal well" and sometimes it goes sketching the solution (see below list for more specific comments). To me this needs to be avoided. I still believe (I mentioned it in my first review of the earlier versions of the document a while back) proper explanations behind selecting the requirements could help reducing the confusion created by such mix specially for first time readers. Comments on requirements: Req 1: 1(a) "Should also deal well with" does not provide much requirements, does it? more clarification is needed to understand the issue and the requirements. Req 2: Here it argues about self-fairness and being fair against TCP flows. Later in Req 11 it mentions more than self-fair and TCP. So I am a bit confused between these two requirements. I think it will be much better requirement if it is specified which are the competing flows we should be concerned about. I know the design team have come up with a list of competing flows which they think the evaluation should be done against. I would suggest to add that list here. I also feel that as this document suggest quit a lot of possibilities it should define "what is fair" or at least say that "possible definition can be found in document XYZ (e.g. eval draft)". Req 4: "Extra information could be added to the packets to provide more detailed information on actual send times (as opposed to sampling times), but should not be required". is this a requirement or guideline? It implicitly means the solution has to support both "sampling times" and "actual send time" even if it decides to operate on actual send time. if this is the case, cant we explicitly say that? 4(a) I hope this is also valid for any future signaling schemes. Req 5: I believe the solution space for backchannel can include more that just RTP header extension and I don't know about WG consensus that we only have to stick with RTP header extension as an alternative to RTCP, right? May be the requirement here really is that the alternatives to RTCP is allowed but they have to follow sub-bullet 5(b),5(c), 5(d) and 5(f) seriously and should show proper gain of not using RTCP according to AVPF/SAVPF profile. Req 6: isn't this covered by sub-bullet 5(f) in Req 5? to me this is just a design choice to achieve 5(f). Req 8: I am really thinking hard here on how to realize this as requirement. Looking at the current Internet I think the only way to achieve this is to allow increasing delay. The application (perhaps the "user of the application" is best to use here) may not like it and even decided to cut the session or it could allow such high delay for the time being. In plain English keep pumping data to the network until the user cuts the session. is this the requirement here? Req 10: I will say the main requirement is fine and we don't need those sub-bullets to discuss solution scope (as Bill Ver Steeg said). Unless that is also an intention of this document. Finally, I think three more things need to be discussed - 1) evaluation based on real codec and/or synthetic codec. In the last IETF88 ,meeting there were lots of discussions and opinions on that which boil down to the fact that we might need both of them. But I didnt see which requirement we were trying to address there from this document. Here I only see once stated "subjectively". I think our evaluation strategies should be driven from the requirement document where we need to ensure the requirements are fulfilled. 2) the interaction between user of RMCAT solution (applications) and the RMCAT solution. There is a deliverable from RMCAT WG on that topic. But there were no requirements on that. There were also some discussions about interaction between encoder and congestion control algorithm in the last IETF88 meeting. Shouldn't there be any requirements on the congestion control algorithm that it takes input from applications? 3) mentioning of circuit breaker, however I am not sure if that is a requirement to the application (user of RMCAT solution) or to the congestion control solution itself. That is so far what I have. -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies 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 zaheduzzaman.sarker@ericsson.com Mon Dec 2 08:13:13 2013 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 6097F1AC863 for ; Mon, 2 Dec 2013 08:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 e1LXFvk3O_05 for ; Mon, 2 Dec 2013 08:13:11 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id F0AF81A1F5B for ; Mon, 2 Dec 2013 08:12:45 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-75-529cb17a83a1 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id EE.78.22496.A71BC925; Mon, 2 Dec 2013 17:12:43 +0100 (CET) Received: from [150.132.141.79] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.347.0; Mon, 2 Dec 2013 17:12:42 +0100 Message-ID: <529CB17A.1000309@ericsson.com> Date: Mon, 2 Dec 2013 17:12:42 +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: Michael Welzl , rmcat WG References: <96FB83A5-23BD-4BAC-9D1A-204913BC342E@netapp.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+JvrW71xjlBBrdbWCx+nN3JarH65gc2 ByaPJUt+MnmsXv2QOYApissmJTUnsyy1SN8ugSvj/oLJLAU7eSpuPZrM0sD4l7OLkZNDQsBE 4srJPWwQtpjEhXvrgWwuDiGBE4wSx1/sY4dwVjNKvJh+lgWkildAW2LLhC6wDhYBFYnpR+Yz dzFycLAJ2Eg8XuwHEuYXkJTY0LCbGcQWFYiSOH/uJRNEq6DEyZlPwMaICDhKdL34ARYXFnCX 2D3vCSuILSSwnUliy+UKEJtTwE5i1plesDnMArYSF+ZcZ4Gw5SWat84GWyskoCvR9TJuAqPg LCQbZiHpmIWkYwEj8ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMCgPbjlt9EOxpN7 7A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKOH38WNnxso7t7peth2f r9Z3hPPIIrsfFp/+F58TNl+Yfn/6u5wK+eqmtcmKW07Zd7FoeEvvaD6zrO9NSoLLs+DDIe++ fHqudV3bPDt/sejxpclV4j3vrWwUI8Tu/30a/+bj37vmF4XCdtzK5pDsv3W5O4a9z+taahSf ZPHanaxTq5zvhOWZKbEUZyQaajEXFScCALmyWyEoAgAA Subject: Re: [rmcat] MW's review of draft-ietf-rmcat-cc-requirements-00 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, 02 Dec 2013 16:13:13 -0000 On 2013-11-25 11:28, Michael Welzl wrote: > > => I think this goes into too much detail and leaves too many > questions open. Don't get me wrong, the things you say here are good > "food for thought" for the group, but as we make progress towards a > real requirements document most of the text in section 2 is probably > useless. We need to specify something that we require, and agree on > something here. +1 > > I tried to address this with my previous email to the list with > subject "Fairness". Let's see what happens. > > > 3. is about coupled congestion control. I think that the right way to > specify this requirement is to point to the other document (whatever > document that will be). Say that "the algorithm should be able to be > interoperate with the mechanism that couples the congestion control > of flows traversing the same bottleneck, specified in draft-YZ." and > not more than that. I am not really sure about the "not more than that" part. A solution can within itself have mechanisms to use information across multiple flow and handle the rate control efficiently. To me we should allow both use of cross traffic information internally and via some external mechanism. BR Zahed -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies 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 vsingh.ietf@gmail.com Mon Dec 2 12:41:25 2013 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 D69B01ADE71 for ; Mon, 2 Dec 2013 12:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rl81X37lnHuW for ; Mon, 2 Dec 2013 12:41:23 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71C1AD72A for ; Mon, 2 Dec 2013 12:41:23 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so21155196ieb.8 for ; Mon, 02 Dec 2013 12:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=KmNo146/bAWmoFuInxrAPp/1r6OyrFk4jiq7UaJj63A=; b=Va8IIWtjXIfE0V8oC4yszFd7u7IWF4euk/A4r7fHCyAVKEKPcf9SOlmc41idUyAsng bUDPAci1XRXOjwrD0lu3jvkD0ZMFvzJB4pG5bG50I21D1X3KXzTCLogGrrqRjYIsfaCY 429wI+SDsgxSy9jqLc8f01ZagkuFdtTzjoXiC8G+Z93ffqJwPScASb+FuaBF4ij/baBh eRMnkG2LKr9fv8qE0MRGDUBtTZquER7yUnr2WjksNPcH3PyYYCv233jr9FekHqLFviKz JofhVpQwEIpZM6XlkWE2AD82FfbiSZU0kKKINoPQdZPODdCzuqUJwnX1N6iHWQbB27LY xf3w== X-Received: by 10.50.26.98 with SMTP id k2mr19810380igg.19.1386016880454; Mon, 02 Dec 2013 12:41:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Mon, 2 Dec 2013 12:41:00 -0800 (PST) From: Varun Singh Date: Mon, 2 Dec 2013 22:41:00 +0200 Message-ID: To: rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [rmcat] Packet Video 2013: Call for Participation 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, 02 Dec 2013 20:41:26 -0000 Packet Video 2013 December 12th and 13th San Jose, CA USA Call for Participation The 20th International Packet Video Workshop (PV 2013) is devoted to presen= ting technological advancements and innovations in video and multimedia transmis= sion over packet networks, in particular wireless and Internet networks. The wor= kshop provides a unique venue for people from the media coding and networking fie= lds to meet, interact and exchange ideas. Its charter is to promote the researc= h and development in both established and emerging areas of video streaming and multimedia networking. PV 2013 will be held in San Jose, CA, USA, on Decemb= er 12th and 13th. The program is available at http://pv2013.itec.aau.at/workshop-program/ and provides the following highlights: Keynotes - Jason Gaedtke, Google YouTube, "Optimizing QoE in Large-Scale Video Netw= orks" - Ion Stoica, UC Berkeley and Conviva, "Improving Video Quality by Information Sharing" - Will Law, Akamai, "Double, Double, Toil and Trouble, Bandwidth Grows and Congestion Bubbles" Special Sessions - Adaptive Streaming - Web-RTC 2.0 - Information-Centric Networks - Low-Latency Interactive Video Regular Sessions - Visibility and Video Quality - Video Delivery and Scalable Coding - Poster Session Social Events - Breakfasts, coffee breaks and lunches are included in registration - Workshop dinner is on December 12th Best-Presentation Awards sponsored by Samsung Registration - Register at http://pv2013.itec.aau.at/registration/ - Author Registration (Paper or poster/demo): 250 USD - Non-author Non-student Registration: 150 USD - Non-author Student Registration: 75 USD ORGANIZATION General Co-Chairs Ali C. Begen, Cisco (Canada) Bernd Girod, Stanford Univ. Technical Program Co-Chairs John Apostolopoulos, Cisco (USA) P=E5l Halvorsen, University of Oslo Publicity Chair Christian Timmerer, AAU Klagenfurt Publications Chair Zhi Li, Cisco (USA) Steering Committee Chang Wen Chen, SUNY Buffalo, USA Tsuhan Chen, Cornell, USA Reha Civanlar, Ozyegin Univ., Turkey Pascal Frossard, EPFL, Switzerland Bernd Girod, Stanford Univ., USA Jin Li, Microsoft, USA Fernando Pereira, IST-IT, Portugal Amy Reibman, AT&T, USA Mihaela van der Schaar, UCLA, USA Ralf Schaefer, HHI, Germany Eckehard Steinbach, TUM, Germany Ming-Ting Sun, Univ. of Wash., USA Further Information http://pv2013.itec.aau.at/ Host: CISCO Financial Sponsor: Alpen-Adria-Universit=E4t Klagenfurt, Austria Technical Co-Sponsor: IEEE Communication Society From michawe@ifi.uio.no Wed Dec 4 04:11:07 2013 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 512B41AE103 for ; Wed, 4 Dec 2013 04:11:07 -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, RP_MATCHES_RCVD=-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 yQpJRpwc_xf2 for ; Wed, 4 Dec 2013 04:11:04 -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 5F5EE1ADFA0 for ; Wed, 4 Dec 2013 04:11:04 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VoBIC-0001lT-Hv; Wed, 04 Dec 2013 13:11:00 +0100 Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26] helo=dhcp-172-17-158-124.eduroam.lapwing.private.cam.ac.uk) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VoBIC-0005oG-3k; Wed, 04 Dec 2013 13:11:00 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <529CB17A.1000309@ericsson.com> Date: Wed, 4 Dec 2013 13:10:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95F93EF5-3E0E-4F21-9DCE-124A0B8CFD9F@ifi.uio.no> References: <96FB83A5-23BD-4BAC-9D1A-204913BC342E@netapp.com> <529CB17A.1000309@ericsson.com> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 10533 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: FC150EADC40C24411AAD194F56489ADF0DDC031F X-UiO-SPAM-Test: remote_host: 131.111.184.26 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 4 max/h 2 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] MW's review of draft-ietf-rmcat-cc-requirements-00 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, 04 Dec 2013 12:11:07 -0000 >> 3. is about coupled congestion control. I think that the right way to >> specify this requirement is to point to the other document (whatever >> document that will be). Say that "the algorithm should be able to be >> interoperate with the mechanism that couples the congestion control >> of flows traversing the same bottleneck, specified in draft-YZ." and >> not more than that. > I am not really sure about the "not more than that" part. A solution = can within itself have mechanisms to use information across multiple = flow and handle the rate control efficiently. To me we should allow both = use of cross traffic information internally and via some external = mechanism. It's a possiblity, but certainly nothing worth *requiring*. Else, why do = we write the other document at all? Cheers, Michael From zaheduzzaman.sarker@ericsson.com Wed Dec 4 05:47:19 2013 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 C04D81AE11B for ; Wed, 4 Dec 2013 05:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 TWthYsKRaB4V for ; Wed, 4 Dec 2013 05:47:18 -0800 (PST) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0E1AE260 for ; Wed, 4 Dec 2013 05:47:17 -0800 (PST) X-AuditID: c1b4fb28-b7fb38e000004238-e7-529f32617447 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 85.9B.16952.1623F925; Wed, 4 Dec 2013 14:47:14 +0100 (CET) Received: from [150.132.141.79] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.347.0; Wed, 4 Dec 2013 14:47:13 +0100 Message-ID: <529F3261.4060403@ericsson.com> Date: Wed, 4 Dec 2013 14:47:13 +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: Michael Welzl References: <96FB83A5-23BD-4BAC-9D1A-204913BC342E@netapp.com> <529CB17A.1000309@ericsson.com> <95F93EF5-3E0E-4F21-9DCE-124A0B8CFD9F@ifi.uio.no> In-Reply-To: <95F93EF5-3E0E-4F21-9DCE-124A0B8CFD9F@ifi.uio.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvrW6S0fwggwf7OCx+nN3JarH65gc2 ByaPJUt+MnmsXv2QOYApissmJTUnsyy1SN8ugSvj6I4HzAU9PBUb1p1na2D8xNnFyMkhIWAi cfLdV3YIW0ziwr31bF2MXBxCAicYJe49bWeHcFYzSuz6spgJpIpXQFuidf0mVhCbRUBFYm7f BuYuRg4ONgEbiceL/UDC/AKSEhsadjOD2KICURLnz72EahWUODnzCQuILSKgJnFi+Wo2EJtZ QFbi+tudYLawgLvE7nlPWCH2djJLXL7yF6yZU8BOYuvJPmaIBluJC3Ous0DY8hLNW2eD3SAk oCvR9TJuAqPQLCTrZiHpmIWkYwEj8ypGyeLU4uLcdCNDvdz03BK91KLM5OLi/Dy94tRNjMBw Prjlt8YOxu5r9ocYpTlYlMR5q2Z2BgkJpCeWpGanphakFsUXleakFh9iZOLglGpgXHHMNnTZ /Te814U+rD+95IX5W+t4kYf6bfINwaJPHgVtM+c4LML5LS6yqjTsXWr1RabUWS3LqhV1Tp3Z tuzA011z4+3kw65ckj/Md4fHzyFXWSWkNiDj5F3LZS63dU2ZH4beCWxarqqt3GxesTCWp1dJ u03TQebl3I9BGYKrpzfd+PDV50eVEktxRqKhFnNRcSIAYbl6WDUCAAA= Cc: rmcat WG Subject: Re: [rmcat] MW's review of draft-ietf-rmcat-cc-requirements-00 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, 04 Dec 2013 13:47:20 -0000 On 2013-12-04 13:10, Michael Welzl wrote: >>> 3. is about coupled congestion control. I think that the right way to >>> specify this requirement is to point to the other document (whatever >>> document that will be). Say that "the algorithm should be able to be >>> interoperate with the mechanism that couples the congestion control >>> of flows traversing the same bottleneck, specified in draft-YZ." and >>> not more than that. >> I am not really sure about the "not more than that" part. A solution can within itself have mechanisms to use information across multiple flow and handle the rate control efficiently. To me we should allow both use of cross traffic information internally and via some external mechanism. > > It's a possiblity, but certainly nothing worth *requiring*.Else, why do we write the other document at all? I believe the requiring part is the "merge of information across the flows" and how does the algorithm realizes that requirement is up to the respective designers. They can invent their own as a part of the solution or they can point to the some external mechanism. or do you think we should create a requirement to justify other documents? Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies 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 michawe@ifi.uio.no Wed Dec 4 05:59:25 2013 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 4562C1AE237 for ; Wed, 4 Dec 2013 05:59:25 -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, RP_MATCHES_RCVD=-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 d49KTy4tqiQR for ; Wed, 4 Dec 2013 05:59:22 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7391AE216 for ; Wed, 4 Dec 2013 05:59:22 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VoCz0-00047h-Sf; Wed, 04 Dec 2013 14:59:18 +0100 Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26] helo=dhcp-172-17-158-124.eduroam.lapwing.private.cam.ac.uk) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VoCz0-0004np-EF; Wed, 04 Dec 2013 14:59:18 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <529F3261.4060403@ericsson.com> Date: Wed, 4 Dec 2013 14:59:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A3F7048-39E4-406A-ADF7-BCE3BBFCBA03@ifi.uio.no> References: <96FB83A5-23BD-4BAC-9D1A-204913BC342E@netapp.com> <529CB17A.1000309@ericsson.com> <95F93EF5-3E0E-4F21-9DCE-124A0B8CFD9F@ifi.uio.no> <529F3261.4060403@ericsson.com> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 7 sum rcpts/h 16 sum msgs/h 10 total rcpts 10551 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: 3552A3CA54776FEFA8D60FD4DDBF4C933A097ADB X-UiO-SPAM-Test: remote_host: 131.111.184.26 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 16 max/h 7 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] MW's review of draft-ietf-rmcat-cc-requirements-00 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, 04 Dec 2013 13:59:25 -0000 On 4. des. 2013, at 14:47, Zaheduzzaman Sarker = wrote: >=20 >=20 > On 2013-12-04 13:10, Michael Welzl wrote: >>>> 3. is about coupled congestion control. I think that the right way = to >>>> specify this requirement is to point to the other document = (whatever >>>> document that will be). Say that "the algorithm should be able to = be >>>> interoperate with the mechanism that couples the congestion control >>>> of flows traversing the same bottleneck, specified in draft-YZ." = and >>>> not more than that. >>> I am not really sure about the "not more than that" part. A solution = can within itself have mechanisms to use information across multiple = flow and handle the rate control efficiently. To me we should allow both = use of cross traffic information internally and via some external = mechanism. >>=20 >> It's a possiblity, but certainly nothing worth *requiring*.Else, why = do we write the other document at all? >=20 > I believe the requiring part is the "merge of information across the = flows" and how does the algorithm realizes that requirement is up to the = respective designers. They can invent their own as a part of the = solution or they can point to the some external mechanism. Agreed. But hopefully anything other than using the external mechanism = won't buy you much, or else that other mechanism isn't very useful. > or >=20 > do you think we should create a requirement to justify other = documents? Clearly not. My concern was to say "an algorithm must take care of = cc-coupling" while we have another document describing a mechanism that = does cc-coupling, because that implicitly assumes that the other = document is worthless and everyone is required to build their own, = better solution. But yes, you can have algorithm-specific ways of = sharing things and could then do better than a more generic external = mechanism perhaps. Cheers, Michael From randell-ietf@jesup.org Sat Dec 21 00:39:42 2013 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 3C01D1AE185 for ; Sat, 21 Dec 2013 00:39:42 -0800 (PST) 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 WlB5lywuu_xC for ; Sat, 21 Dec 2013 00:39:37 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9C1AE0C0 for ; Sat, 21 Dec 2013 00:39:37 -0800 (PST) Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:4370 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VuI5u-000A4j-P0 for rmcat@ietf.org; Sat, 21 Dec 2013 02:39:34 -0600 Message-ID: <52B553AC.5080004@jesup.org> Date: Sat, 21 Dec 2013 03:39:08 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <96FB83A5-23BD-4BAC-9D1A-204913BC342E@netapp.com> In-Reply-To: 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 Subject: Re: [rmcat] MW's review of draft-ietf-rmcat-cc-requirements-00 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: Sat, 21 Dec 2013 08:39:42 -0000 Note: comments based on work-in-progress including edits for Bill Ver Steeg's comments. On 11/25/2013 5:28 AM, Michael Welzl wrote: > Hi, > > I'm sending my comments on this draft now, as I think they're largely orthogonal to Bill's: > > > Abstract: "needs by low-delay" seems broken. I'd end this (the second) sentence after "Web pages". (strange to say "the TCP algorithms" and unnecessary anyway I think. done > 1. Intro: ' "as fast as possible" mode' is weird, somehow fix this wording please. done > 2. (fairness) > > => I think this goes into too much detail and leaves too many questions open. Don't get me wrong, the things you say here are good "food for thought" for the group, but as we make progress towards a real requirements document most of the text in section 2 is probably useless. We need to specify something that we require, and agree on something here. > > I tried to address this with my previous email to the list with subject "Fairness". Let's see what happens. Removed sub-bullets. > 3. is about coupled congestion control. I think that the right way to specify this requirement is to point to the other document (whatever document that will be). Say that "the algorithm should be able to be interoperate with the mechanism that couples the congestion control of flows traversing the same bottleneck, specified in draft-YZ." and not more than that. Included reference, some rewording. > 4. "leverage existing information about the incoming flows" is strange... I think this item is based on a "coupled congestion control" way of thinking, but I think we should really regard the congestion control algorithms as per-flow entities; this gives us a better separation of the problem space, and is more in line with the current proposals too. "packet sizes" seems out of place in the list of "leveraged information", btw, as it's a pre-determined factor that the algorithm simply knows about. The last sentence ("Extra information...") seems unnecessary to me. Reworked some, moved last sentence into a sub-bullet, "incoming flows" -> "incoming flow". > 8. (interaction with TCP) > => here I suggested "not starve TCP and not be starved by TCP" in my separate email on "Fairness" to the list. I think that should do it, rather than this somewhat lengthy discussion. I didn't touch this (yet). We can discuss more; we may end up yanking it for being too like "discussion". > 9. "stable and low-delay" seems grammatically broken here, and I'd rather avoid mentioning particular AQMs but just say that it should interoperate well with Active Queue Manamagement mechanisms. Eliminated reference to specific AQMs. > > 10. too much detail here, I think - I would assume that the first paragraph, without sub-items a-d, is enough? I'm on the fence - I don't want some of these issues/options to be ignored; for example a flow may have a nascent state where data isn't available yet but the algorithm can start gathering data or probing. > > 11. There will be a test suite RFC, right? In this case, just like with coupled congestion control, I'd just say that it should work well in accordance with the tests specified in document xy. I'm not assuming that everything will be tested for or that only those things tested should be used in evaluating how well an algorithm meets the requirements. > > > I hope this is helpful! Very! -- Randell Jesup -- rjesup a t mozilla d o t com From randell-ietf@jesup.org Sat Dec 21 01:01:48 2013 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 A1E3D1A1F5F for ; Sat, 21 Dec 2013 01:01:48 -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 DpiG-J-5BKJs for ; Sat, 21 Dec 2013 01:01:46 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CFDBC1A1F33 for ; Sat, 21 Dec 2013 01:01:46 -0800 (PST) Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:4403 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VuIRM-000FGI-7j for rmcat@ietf.org; Sat, 21 Dec 2013 03:01:44 -0600 Message-ID: <52B558DD.3070008@jesup.org> Date: Sat, 21 Dec 2013 04:01:17 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <529CA5BC.9000508@ericsson.com> In-Reply-To: <529CA5BC.9000508@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 Subject: Re: [rmcat] review of draft-ietf-rmcat-cc-requirements-00 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: Sat, 21 Dec 2013 09:01:48 -0000 On 12/2/2013 10:22 AM, Zaheduzzaman Sarker wrote: > Hi, > > I was waiting for -01 version but decided to go against it. I think > some of the points I mentioned here were already touched by other > reviewers (now you know why I was waiting) but perhaps my version > gives a different view. > > My comments on draft-ietf-rmcat-cc-requirements-00 below- > > In general this draft lists possible requirements and hints for > evaluating congestion control algorithms. However, this draft ends up > being a mix of general requirements and design specifications/choices. > Sometime it only mentions a requirement as "deal well" and sometimes > it goes sketching the solution (see below list for more specific > comments). To me this needs to be avoided. Agreed it likely still goes too far in discussing the solution space, though it also must provide a framework for the WG to evaluate the relative fitness of solutions. Hopefully the update will be better, though it likely will still need some more refinement. > > I still believe (I mentioned it in my first review of the earlier > versions of the document a while back) proper explanations behind > selecting the requirements could help reducing the confusion created > by such mix specially for first time readers. > > > Comments on requirements: > > Req 1: 1(a) "Should also deal well with" does not provide much > requirements, does it? more clarification is needed to understand the > issue and the requirements. reworded with a little more detail; removed "deal well with" > > Req 2: Here it argues about self-fairness and being fair against TCP > flows. Later in Req 11 it mentions more than self-fair and TCP. So I > am a bit confused between these two requirements. I think it will be > much better requirement if it is specified which are the competing > flows we should be concerned about. I know the design team have come > up with a list of competing flows which they think the evaluation > should be done against. I would suggest to add that list here. > > I also feel that as this document suggest quit a lot of possibilities > it should define "what is fair" or at least say that "possible > definition can be found in document XYZ (e.g. eval draft)". I limited the discussion of fairness even further here. Per previous presentations to the WG, defining "what is fair" can lead to the heat death of the universe.... I'll note Michael Welzl has proposed something, but it's so general that I'm not sure it actually leads to any useful addition over the high-level comment here. > > > Req 4: "Extra information could be added to the packets to provide more > detailed information on actual send times (as opposed to > sampling times), but should not be required". is this a > requirement or guideline? It implicitly means the solution has to > support both "sampling times" and "actual send time" even if it > decides to operate on actual send time. if this is the case, cant we > explicitly say that? This is saying that the algorithm can add data to outgoing packets to provide more reliable timestamping than is available from normal RTP timestamps. (e.g. a header extension with higher-resolution and/or closer-to-actual-sending-time data). > > 4(a) I hope this is also valid for any future signaling schemes. > > Req 5: I believe the solution space for backchannel can include more > that just RTP header extension and I don't know about WG consensus > that we only have to stick with RTP header extension as an alternative > to RTCP, right? May be the requirement here really is that the > alternatives to RTCP is allowed but they have to follow sub-bullet > 5(b),5(c), 5(d) and 5(f) seriously and should show proper gain of not > using RTCP according to AVPF/SAVPF profile. Modified to say "one alternative would be" to not rule out others (and some other edits from previous feedback). > > Req 6: isn't this covered by sub-bullet 5(f) in Req 5? to me this is > just a design choice to achieve 5(f). Yes, mostly. Removed (though people shouldn't forget that they can delay-and-piggyback feedback to some degree). > > Req 8: I am really thinking hard here on how to realize this as > requirement. Looking at the current Internet I think the only way to > achieve this is to allow increasing delay. The application (perhaps > the "user of the application" is best to use here) may not like it and > even decided to cut the session or it could allow such high delay for > the time being. In plain English keep pumping data to the network > until the user cuts the session. is this the requirement here? > > > Req 10: I will say the main requirement is fine and we don't need > those sub-bullets to discuss solution scope (as Bill Ver Steeg said). > Unless that is also an intention of this document. This is important enough I wanted to emphasize it to solution authors. Existing proposals have problems in this area. > > > Finally, I think three more things need to be discussed - > 1) evaluation based on real codec and/or synthetic codec. In the last > IETF88 ,meeting there were lots of discussions and opinions on that > which boil down to the fact that we might need both of them. But I > didnt see which requirement we were trying to address there from this > document. Here I only see once stated "subjectively". I think our > evaluation strategies should be driven from the requirement document > where we need to ensure the requirements are fulfilled. > 2) the interaction between user of RMCAT solution (applications) and > the RMCAT solution. There is a deliverable from RMCAT WG on that > topic. But there were no requirements on that. There were also some > discussions about interaction between encoder and congestion control > algorithm in the last IETF88 meeting. Shouldn't there be any > requirements on the congestion control algorithm that it takes input > from applications? > 3) mentioning of circuit breaker, however I am not sure if that is a > requirement to the application (user of RMCAT solution) or to the > congestion control solution itself. I have not addressed these yet. I'm open to more detailed suggestions or discussion. Thanks! -- Randell Jesup -- rjesup a t mozilla d o t com From internet-drafts@ietf.org Sat Dec 21 01:11:40 2013 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 8C67E1A1F1A; Sat, 21 Dec 2013 01:11:40 -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] 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 H3809aeIuzox; Sat, 21 Dec 2013 01:11:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 884131A1F19; Sat, 21 Dec 2013 01:11:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131221091138.4601.37657.idtracker@ietfa.amsl.com> Date: Sat, 21 Dec 2013 01:11:38 -0800 Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-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: Sat, 21 Dec 2013 09:11:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-01.txt Pages : 9 Date : 2013-12-21 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. This document is derived from draft-jesup-rtp-congestion-reqs [I-D.jesup-rtp-congestion-reqs]. 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-cc-requirements-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 dave.taht@gmail.com Sun Dec 29 16:02:17 2013 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 AF89B1AE330; Sun, 29 Dec 2013 16:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xZOc6SZSUCdZ; Sun, 29 Dec 2013 16:02:15 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 052301AE0A7; Sun, 29 Dec 2013 16:02:14 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u56so9542371wes.22 for ; Sun, 29 Dec 2013 16:02:09 -0800 (PST) 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=If5vyYo9jPzxDKONGfxPPawc89EJdKaCA68e7fV5WE8=; b=JeC5hsZqy/Ab2BuKg4nYQPtBv1XZvEh0/52BrDJAr5oY4rMmSarS+jW4VgKBjE+Nov jqc1e+hCTmImedSUJpPu6qdsx+R9f+Kqg2B1gklgWq1F44imGhGSWoTyJHTd+CMBw9DR ZkIZ6bmoURNKfsVjCrpu8TRH7byJRkN3wqNZOO31A5v2uE7+bzwMFdSVaAqD9bvISYxS B27qWkmQKIpzXp/YWFgd68KMuacUktQBvZQaGxf0WgXyDR7pDAcmoGM3zPT/lL7IbOa7 7DzkOPQpr4HoNT2vUDYV80EOrRN3/can+T5k37k+T+l6S1IPEcsPY7Iu1w9oroC1GRHh I6ZQ== MIME-Version: 1.0 X-Received: by 10.180.198.43 with SMTP id iz11mr41849974wic.0.1388361728931; Sun, 29 Dec 2013 16:02:08 -0800 (PST) Received: by 10.217.123.69 with HTTP; Sun, 29 Dec 2013 16:02:08 -0800 (PST) Date: Sun, 29 Dec 2013 16:02:08 -0800 Message-ID: From: Dave Taht To: "rmcat@ietf.org" , rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [rmcat] 5 tuples and rmcat-cc-requirements-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, 30 Dec 2013 00:02:18 -0000 I finally had a chance to read over http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01 and also work at reproducing some of the difficulties present in the current implementation of chrome in light of the two papers presented at the last ietf on google congestion control. I went through tons of tests and packet captures that pretty much reproduced the legion of problems documented in https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-we= brtc and the other paper presented at ietf... and also fed webrtc traffic through the fq_codel and pie queue management systems (with pretty good results). I have tons of captures from each experiment if anyone wants them. So, I have some comments on this requirements document. (I'm new to paying attention on rmcat, so a few of my questions are probably answered by some document I haven't read yet. Steers appreciated. for all I know I'm on the wrong mailing lists too. Sorry) In particular, the flows I was looking at multiplexed voice and video on the same 5 tuple. I am curious as to the justification for this, as voice (without silence suppression) is isochronous and video is not. (is silence suppression used in webrtc?) To me, multiplexing these two very different flows on the same ports is not a good idea except under extreme port pressure, and not useful in ipv6 or in non-natted environments at all. Even in a natted environment, saving a single port is a false savings as (for example) dns lookups punch dozens of holes through nat on a regular basis. Requiring that in most or all cases these two flow types be on unique 5 tuples would give smarter queue management techniques on routers (like sfq, or sqf (deployed at FT), or fq_codel (deployed at free.fr)), a fighting chance. In particular it gives voice much higher probability for drop-and-delay free behavior, and analyzing the delta in drops and delay between a separate voice tuple and video tuple could provide insight as to the congestion in the system. In current implementations, is it possible to force flows onto different tuples? What are the other flaws in suggesting or requiring a different tuple? (note I'm not suggesting bulk data traffic get unique 5 tuples per flow) Some comments on section 3 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 might argue that looking at the traffic on the whole browser would be good. The browser deprioritizing background web page loads while a webrtc session is active would be useful in the presence of congestion. B. The most correlated bandwidth usage would be with other flows on the same 5-tuple, but there may be use in coordinating measurement and control of the local link(s). As I note above you can get more congestion information from a pair of flows than one. C. Use of information about previous flows, especially on the same 5-tuple, may be useful input to the algorithm, especially to startup performance of a new flow. A 4 tuple may also provide insight, or even two (ip to ip) 4B. When additional input signals such as ECN are available, they should be utilized if possible. I would not mind seeing an implementation that negotiated ECN, but it is out of scope on this document. Is it discussed elsewhere, or implemented elsewhere? Is an ipv6 version of webrtc implemented anywhere? I am under the impression it can be made to work in freeswitch... 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. And in fact, may not preserve them. It would be good to be aware if they are being preserved in both directions and mark appropriately, and also to probe if packets with particular classifications are being dropped or treated weirdly. This includes detecting for e2e ECN awareness. 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. faster-than-audio? RTCP Signalling? what? I still have to think about RTCP signalling as it's very hard to pick out of the data I have, if it's even in there. 10. The algorithm should quickly adapt to initial network conditions at the start of a flow. This should occur both if the initial bandwidth is above or below the bottleneck bandwidth. The algorithm I looked over has particularly bad behavior on taking back bandwidth after it has been used up by another flow, taking many seconds to ramp up. I like the idea of periodically probing to ratchet up to a higher rate, with a slow-start-like burst (a higher resolution frame sent in parallel with lower rate data). But in terms of the requirements, adding a The algorithm should quickly recover from a loss in bandwidth, recovering voice first, if possible. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From harald@alvestrand.no Mon Dec 30 06:09:13 2013 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 A42711AE19A for ; Mon, 30 Dec 2013 06:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 JVLVpfoI0VZr for ; Mon, 30 Dec 2013 06:09:10 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0FB1AE11C for ; Mon, 30 Dec 2013 06:09:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FE3E39E128; Mon, 30 Dec 2013 15:09:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVIHnGO1MyyL; Mon, 30 Dec 2013 15:09:07 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:296a:f534:315c:b493] (unknown [IPv6:2001:470:de0a:27:296a:f534:315c:b493]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5556A39E04C; Mon, 30 Dec 2013 15:09:07 +0100 (CET) Message-ID: <52C17E9F.8060703@alvestrand.no> Date: Mon, 30 Dec 2013 15:09:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Dave Taht , "rmcat@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-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, 30 Dec 2013 14:09:13 -0000 Dave, this is interesting .... I think characterizing what the connection between type-of-traffic and applicable congestion is should be an rmcat issue, but may feed back into RTCWEB and even MMUSIC - so I'm sending this to rmcat only. On 12/30/2013 01:02 AM, Dave Taht wrote: > I finally had a chance to read over > > http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01 > > and also work at reproducing some of the difficulties present in the > current implementation of chrome in light of the two papers presented > at the last ietf on google congestion control. I went through tons of > tests and packet captures that pretty much reproduced the legion of > problems documented in > > https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-webrtc > and the other paper presented at ietf... > > and also fed webrtc traffic through the fq_codel and pie queue > management systems (with pretty good results). I have tons of captures > from each experiment if anyone wants them. > > So, I have some comments on this requirements document. (I'm new to > paying attention on rmcat, so a few of my questions are probably > answered by some document I haven't read yet. Steers appreciated. for > all I know I'm on the wrong mailing lists too. Sorry) > > In particular, the flows I was looking at multiplexed voice and video > on the same 5 tuple. I am curious as to the justification for this, as > voice (without silence suppression) is isochronous and video is not. > (is silence suppression used in webrtc?) This is a curious statement - what characteristic are you thinking about when you say that voice is "isochronous" and video is not? Both of them are produced one time-frame at a time, and both of them cause irritation at the receiver when the frames are displayed in anything but the same cadence. I think the irritation from jitter on voice is quite a bit higher than on video, but stuttering video isn't a good thing either. > > To me, multiplexing these two very different flows on the same ports > is not a good idea except under extreme port pressure, and not useful > in ipv6 or in non-natted environments at all. Even in a natted > environment, saving a single port is a false savings as (for example) > dns lookups punch dozens of holes through nat on a regular basis. > > Requiring that in most or all cases these two flow types be on unique > 5 tuples would give smarter queue management techniques on routers > (like sfq, or sqf (deployed at FT), or fq_codel (deployed at > free.fr)), a fighting chance. In particular it gives voice much higher > probability for drop-and-delay free behavior, and analyzing the delta > in drops and delay between a separate voice tuple and video tuple > could provide insight as to the congestion in the system. How does this effect happen? In particular, does the separation of flows itself create lower loss probability for voice, or are you thinking of systems where the network elements "know" what the flows contain? What about multiplexing between different flows of the same media type? > > In current implementations, is it possible to force flows onto > different tuples? Absolutely - just don't negotiate bundling. > What are the other flaws in suggesting or requiring > a different tuple? > > (note I'm not suggesting bulk data traffic get unique 5 tuples per flow) I wouldn't either. In current deployments, it's multiplexed with the media traffic on the same 5-tuple too - what would you suggest advising it to be bundled with, and why? (dropping the rest of the message - this should be enough for one thread) From michawe@ifi.uio.no Mon Dec 30 09:00:14 2013 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 C54041AE143; Mon, 30 Dec 2013 09:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.538] 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 zCPdVLKZ8FxR; Mon, 30 Dec 2013 09:00:10 -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 2A8C81AE2B4; Mon, 30 Dec 2013 09:00:09 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VxgCA-0003Ot-98; Mon, 30 Dec 2013 18:00:02 +0100 Received: from 089144207156.atnat0016.highway.bob.at ([89.144.207.156] helo=[192.168.1.3]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VxgC5-0003py-TP; Mon, 30 Dec 2013 18:00:02 +0100 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: Michael Welzl Date: Mon, 30 Dec 2013 17:59:52 +0100 To: Dave Taht X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 11183 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7EF5353F7CF375735F3A40245F4F63808A8A370C X-UiO-SPAM-Test: remote_host: 89.144.207.156 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10 max/h 3 blacklist 0 greylist 0 ratelimit 0 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-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, 30 Dec 2013 17:00:15 -0000 Sent from my iPhone On 30. des. 2013, at 01:02, Dave Taht wrote: > I finally had a chance to read over >=20 > http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01 >=20 > and also work at reproducing some of the difficulties present in the > current implementation of chrome in light of the two papers presented > at the last ietf on google congestion control. I went through tons of > tests and packet captures that pretty much reproduced the legion of > problems documented in >=20 > https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-w= ebrtc > and the other paper presented at ietf... >=20 > and also fed webrtc traffic through the fq_codel and pie queue > management systems (with pretty good results). I have tons of captures > from each experiment if anyone wants them. >=20 > So, I have some comments on this requirements document. (I'm new to > paying attention on rmcat, so a few of my questions are probably > answered by some document I haven't read yet. Steers appreciated. for > all I know I'm on the wrong mailing lists too. Sorry) >=20 > In particular, the flows I was looking at multiplexed voice and video > on the same 5 tuple. I am curious as to the justification for this, as > voice (without silence suppression) is isochronous and video is not. > (is silence suppression used in webrtc?) >=20 > To me, multiplexing these two very different flows on the same ports > is not a good idea except under extreme port pressure, and not useful > in ipv6 or in non-natted environments at all. Even in a natted > environment, saving a single port is a false savings as (for example) > dns lookups punch dozens of holes through nat on a regular basis. >=20 > Requiring that in most or all cases these two flow types be on unique > 5 tuples would give smarter queue management techniques on routers > (like sfq, or sqf (deployed at FT), or fq_codel (deployed at > free.fr)), a fighting chance. In particular it gives voice much higher > probability for drop-and-delay free behavior, and analyzing the delta > in drops and delay between a separate voice tuple and video tuple > could provide insight as to the congestion in the system. that's why we want to couple the congestion controllers in such cases. no ne= ed for queuing to regulate fairness, you do it in the sender! >=20 > In current implementations, is it possible to force flows onto > different tuples? What are the other flaws in suggesting or requiring > a different tuple? >=20 > (note I'm not suggesting bulk data traffic get unique 5 tuples per flow) >=20 > Some comments on section 3 >=20 > 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 >=20 > I might argue that looking at the traffic on the whole browser would > be good. The browser deprioritizing background web page loads while a > webrtc session is active would be useful in the presence of > congestion. >=20 > B. The most correlated bandwidth usage would be with other > flows on the same 5-tuple, but there may be use in > coordinating measurement and control of the local link(s). >=20 > As I note above you can get more congestion information from a pair of > flows than one. >=20 > C. Use of information about previous flows, especially on the > same 5-tuple, may be useful input to the algorithm, > especially to startup performance of a new flow. >=20 > A 4 tuple may also provide insight, or even two (ip to ip) >=20 > 4B. When additional input signals such as ECN are available, > they should be utilized if possible. >=20 > I would not mind seeing an implementation that negotiated ECN, but it > is out of scope on this document. Is it discussed elsewhere, or > implemented elsewhere? Is an ipv6 version of webrtc implemented > anywhere? I am under the impression it can be made to work in > freeswitch... >=20 > 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. >=20 > And in fact, may not preserve them. It would be good to be aware > if they are being preserved in both directions and mark appropriately, > and also to probe if packets with particular classifications are being > dropped > or treated weirdly. This includes detecting for e2e ECN awareness. >=20 > 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. >=20 > faster-than-audio? RTCP Signalling? what? >=20 > I still have to think about RTCP signalling as it's very hard to pick > out of the data I have, if it's even in there. >=20 > 10. The algorithm should quickly adapt to initial network conditions > at the start of a flow. This should occur both if the initial > bandwidth is above or below the bottleneck bandwidth. >=20 > The algorithm I looked over has particularly bad behavior on taking > back bandwidth after it has been used up by another flow, taking many > seconds to ramp up. I like the idea of periodically probing to ratchet > up to a higher rate, with a slow-start-like burst (a higher resolution > frame sent in parallel with lower rate data). But in terms of the > requirements, adding a >=20 > The algorithm should quickly recover from a loss in bandwidth, > recovering voice first, if possible. >=20 >=20 > --=20 > Dave T=C3=A4ht >=20 > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe= .html From dave.taht@gmail.com Mon Dec 30 22:37:58 2013 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 7CDAC1AE3E6 for ; Mon, 30 Dec 2013 22:37:58 -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 evinAFra8huv for ; Mon, 30 Dec 2013 22:37:56 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB7F01AE383 for ; Mon, 30 Dec 2013 22:37:55 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so10554644wgh.26 for ; Mon, 30 Dec 2013 22:37:49 -0800 (PST) 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=reSOpbKmNkwvruFMEwDgJTxCEM2tOCkuvzw7pBYsfUA=; b=O6y8jLCB5Y6shji+QLusJn9MGgRq06/jT5hmX+bSTi4SjtzV4ogMpufKXvr6cvOTCZ 355lKukWUILKanstqg1Gg4JMwh9vi/GWJcFI1BwkYoHPe4WhaacWdpKU7pWCuAKDSm0n QydK1kGpQgyZS976WkRmUrje4ElfjR+YtvWfi+P2ETYCc31zoiQJPzjVkgUBPB8cZUDp 9AML4FJHX9RltD98T7bP73lYyq+mYGrWAyObyt5i6DNqhAQsznrSRsDDgYjBe7bnvSYR n5hy9GUGSO2G6zLIPVg1eai6VuEcOxxJynR1Mx77Gcg5B7zZCFg8ZYM1zITsfRNO+x2A aGqg== MIME-Version: 1.0 X-Received: by 10.194.110.138 with SMTP id ia10mr47634890wjb.3.1388471869360; Mon, 30 Dec 2013 22:37:49 -0800 (PST) Received: by 10.217.123.69 with HTTP; Mon, 30 Dec 2013 22:37:49 -0800 (PST) In-Reply-To: <52C17E9F.8060703@alvestrand.no> References: <52C17E9F.8060703@alvestrand.no> Date: Mon, 30 Dec 2013 22:37:49 -0800 Message-ID: From: Dave Taht To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rmcat@ietf.org" Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-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: Tue, 31 Dec 2013 06:37:58 -0000 On Mon, Dec 30, 2013 at 6:09 AM, Harald Alvestrand w= rote: > Dave, this is interesting .... I think characterizing what the connection > between type-of-traffic and applicable congestion is should be an rmcat > issue, but may feed back into RTCWEB and even MMUSIC - so I'm sending thi= s > to rmcat only. > > > > On 12/30/2013 01:02 AM, Dave Taht wrote: >> >> I finally had a chance to read over >> >> http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01 >> >> and also work at reproducing some of the difficulties present in the >> current implementation of chrome in light of the two papers presented >> at the last ietf on google congestion control. I went through tons of >> tests and packet captures that pretty much reproduced the legion of >> problems documented in >> >> >> https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for= -webrtc >> and the other paper presented at ietf... >> >> and also fed webrtc traffic through the fq_codel and pie queue >> management systems (with pretty good results). I have tons of captures >> from each experiment if anyone wants them. >> >> So, I have some comments on this requirements document. (I'm new to >> paying attention on rmcat, so a few of my questions are probably >> answered by some document I haven't read yet. Steers appreciated. for >> all I know I'm on the wrong mailing lists too. Sorry) >> >> In particular, the flows I was looking at multiplexed voice and video >> on the same 5 tuple. I am curious as to the justification for this, as >> voice (without silence suppression) is isochronous and video is not. >> (is silence suppression used in webrtc?) > > > This is a curious statement - what characteristic are you thinking about > when you say that voice is "isochronous" and video is not? > Both of them are produced one time-frame at a time, and both of them caus= e > irritation at the receiver when the frames are displayed in anything but = the > same cadence. On a per packet level, voice is typically one packet ranging in size from 110 bytes to 300 every 10 or 20ms. (the opus codec goes down to 2.5ms) Video, in comparison, consists of a variable number of (often) many packets depending on encoding, subframes, etc. So from this viewpoint voice can be isochronous (lacking silence suppression), and video is not. > I think the irritation from jitter on voice is quite a bit higher than on > video, but stuttering video isn't a good thing either. jitter and loss on voice is often quite annoying. On music it's intolerable= . On video, I would not use the word "stuttering" which implies a max-headroom sort of effect. Partial corruption of the output, blocky output, etc are closer to words I would use. > >> >> To me, multiplexing these two very different flows on the same ports >> is not a good idea except under extreme port pressure, and not useful >> in ipv6 or in non-natted environments at all. Even in a natted >> environment, saving a single port is a false savings as (for example) >> dns lookups punch dozens of holes through nat on a regular basis. >> >> Requiring that in most or all cases these two flow types be on unique >> 5 tuples would give smarter queue management techniques on routers >> (like sfq, or sqf (deployed at FT), or fq_codel (deployed at >> free.fr)), a fighting chance. In particular it gives voice much higher >> probability for drop-and-delay free behavior, and analyzing the delta >> in drops and delay between a separate voice tuple and video tuple >> could provide insight as to the congestion in the system. > > How does this effect happen? Could you be more specific? > In particular, does the separation of flows itself create lower loss > probability for voice, or are you thinking of systems where the network > elements "know" what the flows contain? In nearly any packet scheduled system (drr, sfq,sqf, fq_codel, etc), the separation of flows on a 5 tuple will result in (much) less delay, jitter and loss for the lower rate flows. With sqf and fq_codel, if the rate is low enough there will be near zero queuing delay, jitter and loss on many workloads. I try to encourage people to just try it to get a feel for what happens. openwrt, cerowrt, any modern linux for all of the above, cisco routers do drr, many dsl devices do sfq or sqf in their firmware.... separation of flows does nothing terrible useful on a strict drop tail system, but no harm either. > What about multiplexing between different flows of the same media type? Good question. There are many things I don't understand about webrtc's intended audience. What excites me most about it is the ability to do in-the-building videoconferences without having to go over the internet for them. As for going over the internet... I think the cable industry is too broken (currently) for any e2e congestion control algorithm to work at all with serious cross traffic, with up and downlinks having 2 or more seconds of buffering each. (unless fixed by one of the algorithms above in a 3rd party router) FIOS and DSL users have a fighting chance, 3g and LTE less so, and wifi needs some serious work. So at the moment I'd like to be addressing the fixable e2e problems in gcc (it can't even compete with itself!) and wanted to be able to break things out on tuples to look at the data... before drawing any conclusions on how to multiplex video flows. My gut tells me you want one tuple per voice and per video flow, AND to manage their congestion indicators together, but depending on the level of statistical multiplexing of the video flows they could go on a single tuple. >> In current implementations, is it possible to force flows onto >> different tuples? > > > Absolutely - just don't negotiate bundling. Pointer to a working example? keep hoping there's working ipv6 code out there too, getting the stun and turn stuff out of the loop long enough to look at simpler cases. > >> What are the other flaws in suggesting or requiring >> a different tuple? > > > >> >> (note I'm not suggesting bulk data traffic get unique 5 tuples per flow) > > > I wouldn't either. > In current deployments, it's multiplexed with the media traffic on the sa= me > 5-tuple too - what would you suggest advising it to be bundled with, and > why? My understanding of the use case for that is that it is for p2p file transfer. Given how prone to failure setup has been for this in other protocols it seems to make some sense to bundle it on the video tuple... > (dropping the rest of the message - this should be enough for one thread) > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html