From wes@mti-systems.com Fri Sep 21 09:32:57 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26DE21F8741 for ; Fri, 21 Sep 2012 09:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxnFbwyfKxGl for ; Fri, 21 Sep 2012 09:32:56 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 587D821F8734 for ; Fri, 21 Sep 2012 09:32:53 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q8LGWq7F010175 for ; Fri, 21 Sep 2012 12:32:52 -0400 Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.209] ([69.81.143.209:8127] helo=[192.168.1.116]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 92/E0-29221-4B69C505; Fri, 21 Sep 2012 12:32:52 -0400 Message-ID: <505C96B1.6030203@mti-systems.com> Date: Fri, 21 Sep 2012 12:32:49 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rmcat@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rmcat] WG creation approved X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 16:32:57 -0000 This is both a test of the new RMCAT mailing list as well as an announcement that the WG charter was approved at the last IESG telechat, and chairs have been appointed. There should be an announcement from the IESG Secretary soon. I'm pleased to announce that the chairs will be Lars Eggert and Mirja Kuehlewind. Please use the rmcat@ietf.org mailing list for WG discussion now, rather than the prior rtp-congestion@alvestrand.no list that we've been using in the past. There were some minor charter clarifications during the IESG review; primarily to talk about potentially making Historic any algorithms that we publish at Experimental but then discover significant flaws in, and also to consistently say that any necessary RTP extensions would be handled through coordination with ATVCORE and done in AVTCORE. Thanks to everyone for their hard work getting this started, including the BoF proponents, BoF chairs, and everyone that's been contributing through drafts and the mailing list so far! Now we have some milestones coming up to work towards ... :) -- Wes Eddy MTI Systems From iesg-secretary@ietf.org Fri Sep 21 09:53:54 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E90911E808A; Fri, 21 Sep 2012 09:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5txmyTvRiLO; Fri, 21 Sep 2012 09:53:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AD711E8099; Fri, 21 Sep 2012 09:53:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921165353.28711.52710.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 09:53:53 -0700 Cc: rmcat WG Subject: [rmcat] WG Action: Formed RTP Media Congestion Avoidance Techniques (rmcat) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 16:53:54 -0000 A new IETF working group has been formed in the Transport Area. For additional information please contact the Area Directors or the WG Chairs. RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------ Current Status: Proposed Working Group Chairs: Lars Eggert Mirja Kuehlewind Assigned Area Director: Wesley Eddy Mailing list Address: rmcat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rmcat Archive: http://www.ietf.org/mail-archive/web/rmcat/ Charter of Working Group: Today's Internet traffic includes interactive real-time media, which is often carried via sets of flows using RTP over UDP. There is no generally accepted congestion control mechanism for this kind of data flow. With the deployment of applications using the RTCWEB protocol suite, the number of such flows is likely to increase, especially non- fixed-rate flows such as video or adaptive audio. There is therefore some urgency in specifying one or more congestion control mechanisms that can find general acceptance. Congestion control algorithms for interactive real time media may need to be quite different from the congestion control of TCP: for example, some applications can be more tolerant to loss than delay and jitter. The set of requirements for such an algorithm includes, but is not limited to: - Low delay and low jitter for the case where there is no competing traffic using other algorithms - Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves. - Effective use of signals like packet loss and ECN markings to adapt to congestion The working group will: - Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. This must be completed prior to finishing any Experimental algorithm specifications. - Identify interactions between applications and RTP flows to enable conveying helpful cross-layer information such as per-packet priorities, flow elasticity, etc. This information might be used to populate an API, but the WG will not define a specific API itself. - Determine if extensions to RTP/RTCP are needed for carrying congestion control feedback, using DCCP as a model. If so, provide the requirements for such extensions to the AVTCORE working group for standardization there. - Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM. - Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck. - Define evaluation criteria for proposed congestion control mechanisms, and publish these as an Informational RFC. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Find or develop candidate congestion control algorithms, verify that these can be tested on the Internet without significant risk, and publish one or more of these as Experimental RFCs. - Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one algorithm; in this case it will be one of the objects of the experimentation to determine the applicabilities and relative merits of the algorithms. - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether there are significant flaws, such as ones that turn out to be harmful to flows using or competing with them. If so, the WG will write a document describing the issues encountered and recommending to the IESG to move the specification to Historic status. The work will be guided by the advice laid out in RFC 5405 (UDP Usage Guidelines), RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion Control Algorithms). The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere: - Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE - Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic - Defining active queue management algorithms or modifications to TCP of any kind - Multicast congestion control; common control of multiple unicast flows is in scope - Topologies other than point-to-point connections; implications on multi-hop connections will be considered at a later stage The working group is expected to work closely with the RAI area, including the underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and the applications/protocol suites being developed in the CLUE and RTCWEB working groups. It will also coordinate closely with other Transport area groups working on congestion control, and with the Internet Congestion Control Research Group of the IRTF. Deliverables: - Requirements for congestion control algorithms for interactive real time media as an Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media as an Informational RFC - Requirements for RTCP extensions for use with congestion control algorithms as an input to the AVTCORE WG. - Interactions between applications and RTP flows as an Informational RFC - Identifying and controlling groups of flows as a Proposed Standard RFC - Techniques to detect, instrument or diagnose failing to meet RT schedules as either an Informational RFC or on the Standards Track if needed for interoperability or other aspects that would justify it. - Candidate congestion control algorithm for interactive real time media as Experimental RFCs (likely more than one) - Experimentation and evaluation results for candidate congestion control algorithms as an Informational RFC - One or more recommended congestion control algorithms for interactive real time media as Proposed Standard RFCs Milestones: Dec 2012 - Adopt first WG drafts of requirements and evaluation criteria Dec 2012 - Adopt first WG draft of RTCP extensions for use with congestion control algorithms and interactions between applications and RTP flows (if needed) Jan 2013 - Adopt first congestion control candidate as WG draft Jan 2013 - Adopt first WG draft on identifying and controlling groups of flows Mar 2013 - Submit requirements and evaluation criteria to IESG as Informational May 2013 - Submit RTCP extension requirements for use with congestion control algorithms to AVTCORE (if needed) May 2013 - Submit interactions between applications and RTP flows to IESG as Informational Jun 2013 - Submit first congestion control candidate to IESG for Experimental publication Jul 2013 - Submit identifying and controlling groups of flows to IESG for Standards Track publication Sep 2013 - Publish first draft of evaluation results Sep 2013 - Publish first draft of Standards Track congestion control algorithm Sep 2013 - Publish first draft of techniques to detect, instrument or diagnose failing to meet RT schedules Mar 2014 - Submit techniques to detect, instrument or diagnose failing to meet RT schedules to IESG as Informational May 2014 - Submit congestion control to IESG for Proposed Standard From lars@netapp.com Sun Sep 23 00:16:53 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC45B21F84BF for ; Sun, 23 Sep 2012 00:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.737 X-Spam-Level: X-Spam-Status: No, score=-10.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfdiHfGESPuN for ; Sun, 23 Sep 2012 00:16:53 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id BB26221F84B9 for ; Sun, 23 Sep 2012 00:16:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,469,1344236400"; d="p7s'?scan'208";a="692970035" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 23 Sep 2012 00:16:48 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8N7Glv5005643; Sun, 23 Sep 2012 00:16:47 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0309.002; Sun, 23 Sep 2012 00:16:46 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: Welcome to RMCAT Thread-Index: AQHNmVtk7I1T2w/Y202vPxlndBpxTg== Date: Sun, 23 Sep 2012 07:16:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_EB0F4F66-1E8A-4E08-AE4D-F282DF483FE2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: [rmcat] Welcome to RMCAT X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rmcat WG 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, 23 Sep 2012 07:16:53 -0000 --Apple-Mail=_EB0F4F66-1E8A-4E08-AE4D-F282DF483FE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Welcome to RMCAT! Your chairs will be Mirja and myself. A few administrative bits: * Please start using the rmcat@ietf.org WG list for discussions. = Harald's list can probably be retired at this point. * Familiarize yourself with the final version of the charter = (https://datatracker.ietf.org/wg/rmcat/charter/), and esp. our first few = milestones. Begin discussions on this list. * If you are submitting IDs targeted at the WG, please name them = draft-yourname-rmcat-*, so the tools will pick them up and we can track = them easily. (Resubmit revisions of existing IDs under the same naming = scheme. You can point out in the text which earlier ID they replace.) * Familiarize yourself with the IETF Note Well = (http://www.ietf.org/about/note-well.html). Make sure you comply with = the relevant rules, especially with regards to timely IPR disclosure. * Remember that the WG works continuously on the list year-round, and = face-to-face sessions are for those high-importance issues that need the = additional bandwidth available in a live setting to be resolved. This = means that we'll likely cherry-pick the topics that get face-time at WG = sessions - not everything being worked on on the list will need or get = session time. On the flip side, it's highly unlikely that anything will = get session time that isn't being discussed on the list. So: work on the = list, it's the primary forum. Begin now :-) * The ADs asked for a slot in Atlanta. We don't know yet when or how = long it is. Mirja and me will begin putting a charter together based on = the WG list discussions. Lars= --Apple-Mail=_EB0F4F66-1E8A-4E08-AE4D-F282DF483FE2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkyMzA3MTY1MVowIwYJKoZIhvcNAQkEMRYEFA5m sG/bK+sA90vq8o6xpTnqnGZDMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAJesquTm L9SOJckPreBRu3PUj8molqkZqk5Lrv1EsngqYL7hG52izL5dqXglU6X76J9PTEQODSaOEpgTSjru 1eHalNSePcbqKfqEPh+6sMXOQN/8wznDju0EEu/KxR4Fy3g/u8yyNrP3wAZe9JXoG244khDzXSbi g9nXHqVrxWd9bBv0Oj+J2u+gjoGSm/s2N5RSMOGL31HpliGc5y5vsyaozbZkk+C9kqcLPJfDlv/K 4xKappBvTMbIivwfh9cu5sUmSWTsFSsQlBme937U1OXdwDlmjiEIkcTMiTKrpqS5x/i6m965MnDd GT8Z4pxKt0wCIwhK0opOwjDnb/0YYEcAAAAAAAA= --Apple-Mail=_EB0F4F66-1E8A-4E08-AE4D-F282DF483FE2-- From michawe@ifi.uio.no Mon Sep 24 01:40:07 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A4721F85AE for ; Mon, 24 Sep 2012 01:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEIyLdHlt6gz for ; Mon, 24 Sep 2012 01:40:05 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 0214121F85AD for ; Mon, 24 Sep 2012 01:40:05 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TG4Cx-0008EP-JY; Mon, 24 Sep 2012 10:40:03 +0200 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 1TG4Cw-0005RO-Iq; Mon, 24 Sep 2012 10:40:03 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_755CF64E-2750-464C-9EEA-FE0642B56609" From: Michael Welzl In-Reply-To: Date: Mon, 24 Sep 2012 10:40:01 +0200 Message-Id: <392AA42E-3BFA-4991-B0E9-FA30F276E7D2@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> To: rmcat WG X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 5 sum msgs/h 4 total rcpts 23969 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.7, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.75, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DEDAF17637FD187C10B7D8EC03C8F8B6752386B4 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -56 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9652 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: Stefan Holmer Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 08:40:07 -0000 --Apple-Mail=_755CF64E-2750-464C-9EEA-FE0642B56609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Sorry, this answer is almost ridiculously late... I compensate by being the first one to send a technical discussion = message to the new list :-) On 21. sep. 2012, at 16:20, Stefan Holmer wrote: >=20 > On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl = wrote: > Hi, >=20 > Sorry for bringing this up yet again - but my thoughts just keep = returning to the question of sender-vs.-receiver based congestion = control, because it's a seemingly simple problem for which we should be = able to agree on a clear answer?! >=20 > As most of you probably know by now, I'm critical of a receiver-based = approach as in RRTCC. (In fact, as I will explain further below, I argue = against a *combined* sender+receiver approach). Here is a plus/minus = list as I see it: >=20 >=20 > PLUS no. 1: it helps to reduce the amount of feedback. That's really = the ONLY benefit. >=20 > It also has a small benefit in that it can more easily make use of new = signals as they are introduced, without having to modify the feedback = message, but I guess that argument is a bit hypothetical. Yes, I'd say that's hypothetical :-) because at the end of the day, = there's only so much you can measure... has a packet made it or not, and = how long did it take. I argue for giving all of that information to the = sender if we go for a sender-based approach. =20 >=20 > MINUS no. 1: it requires the same mechanism on the sender and receiver = side, which means that, if RTP becomes a "framework" for congestion = control mechanisms, we must signal which mechanism is used to the other = side. In contrast, we don't have to do this with TCP's (implemented but = not standardized) pluggable congestion control. This is, to me, the = biggest problem, as it requires code updates to happen on both sides for = a new mechanism to be deployed. >=20 > MINUS no. 2: it could make combined congestion control between = multiple flows via the FSE more complicated. Anyway it seems we'll need = an FSE on the sender AND receiver side, but with receiver-based = congestion control, we'll face the question: for two flows between the = same two hosts, sharing the same bottleneck, should the receivers = exchange information and coordinate their feedback, or should the = senders exchange information and coordinate their behavior? =3D> when = congestion control mechanisms are split across sender and receiver, the = right answer to this question becomes a per-mechanism decision. >=20 >=20 > Please amend this list if I'm missing something. Regarding the one = PLUS above, here's a critical look at the benefits of reducing feedback = **via receiver-side congestion control**: >=20 > - less feedback means a greater chance for the feedback to be dropped, = which translates into a greater chance for undesirable sender behavior > - we deal with interactive traffic, in which case a lot of the = feedback could hopefully be piggybacked onto payload packets > - in some cases there will be other parallel flows (e.g. the data = channel in rtcweb) that already give us all the feedback that we need, = this is another chance for feedback reduction > - receiver-side-congestion-control-based feedback reduction as in = RRTCC means to reduce the feedback whenever feedback isn't urgent for = the sender. I'd argue that, in fact, we should reduce feedback only when = the channel carrying it (the backwards channel) is congested, and that = is a generic function, not bound to the sender-side congestion control = behavior. >=20 >=20 > So how urgent is it to reduce feedback, anyway? Some time ago, Bill = Ver Steeg wrote: >=20 > *** > 1- The upstream/return traffic is (generally) assumed to be a precious = resource by the RTP community. This is partially due to multicast = considerations (which we can mostly ignore here) and partially due to = asynchronous networks. Note that the CableTV community has found it = necessary to play games with TCP acks in Cable Modems because of = upstream bandwidth limitations, even for unicast TCP traffic. This is an = ugly hack that I will not defend here, but it is indicative of the = problem space. The net-net is that we have to be somewhat conservative = in our sending of acks, or we will end up in similar trouble. > *** >=20 > As he states, multicast is out of scope. Plus, I think we should care = more about technical reasons than what the RTP community considers to be = a precious resource. As for the CableTV example, one can always find = examples where people started doing useless things :-) but consider = the following: many parallel TCP connections, each sending lots of = feedback, work okay for maaaany end users that 1) surf the Internet or = (bringing it closer to rtcweb thinking) 2) use P2P applications. And = TCP doesn't even do any form of congestion control on ACKs (an RFC = exists but noone uses it (so far)). >=20 > I'm not saying ACKs never cause problems. I'm saying it's probably = rare that they do, and reducing their number WHEN they cause trouble is = good enough (and, I would argue, a better decision). >=20 >=20 > Let's take a step back and summarize the situation: > 1) congestion-control-based-feedback-reduction has at least one = significant MINUS (no. 1), probably two > 2) the benefits of doing it seem minimal > 3) not being based on congestion along the backwards path, it misses = the point somewhat... >=20 >=20 > As a result of the above, I would suggest to move all congestion = control functionality to the sender side and keep the receiver side = dumb, as in TCP, but amended with some generic (i.e. not = mechanism-specific) feedback-reduction functions (ACK congestion = control; piggybacking; omitting feedback when it is known (e.g. via a = signal from the sender) that we get feedback from another flow). >=20 > Alternatively, we could still remove the MINUS no. 1 above by agreeing = on a generic sender behavior. IIRC, in RRTCC, the sender is rather = simple - it follows the rate dictated by the receiver and has a timeout = behavior. If all congestion control mechanisms are installed on the = receiver side only, with the same agreed generic sender behavior for = everyone, we can also have pluggable congestion control without a need = for signalling. >=20 > I agree that if we go for a receiver-based approach, the sender must = be dumb. And the other way around if we go for a sender-based approach. Great! Having one side dumb is the most important thing here IMO. > =20 >=20 > It's just the idea of multiple proposals for congestion control = involving newly described sender AND receiver behavior that strikes me = as bad design. >=20 > Thoughts? >=20 > One benefit I see with having the intelligence at the sender is if you = want to do something more clever when probing the channel, which would = require coordination between the sender and the one who's supposed to = come to some conclusion from the incoming packets. I think Bill Ver = Steeg touched upon something along those lines: >=20 > "Basic senders will simply tell the receiver to gather the data every = N seconds and send it every N seconds (plus when there are problems, as = defined by the specification). More sophisticated senders could drive = more complex relationships, asking the receiver to tabulate/send the = data on demand in semi-real time. This would allow a sophisticated = sender to send a varying data patterns and get the feedback they = require, yet not require too much shared state between the sender and = receiver. As long as the receiver is a simple state machine, I think we = would be OK." That method actually just becomes another entry in the list of = feedback-reduction mechanisms that we already have. Here's an updated summary: 1) I have argued that reducing feedback really isn't all that important. 2) Say, we want to do it (still a good thing, I think). .. a) Then we can and should, first of all, do it based on congestion on = the backward path. .. b) Additionally, it might be possible to reduce feedback because it = can be piggybacked onto payload (as most scenarios would have traffic = flowing both ways). .. c) Additionally, it might be possible to exploit feedback from other = parallel flows (e.g., the data channel in rtcweb) .. d) Additionally, we can do what is written above, let the sender tell = the receiver how much feedback it needs. All of this is possible with having the logic on the sender side only, = and having a dumb receiver. Cheers, Michael --Apple-Mail=_755CF64E-2750-464C-9EEA-FE0642B56609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl = <michawe@ifi.uio.no> = wrote:
Hi,

Sorry for bringing this up yet again - but my thoughts just keep = returning to the question of sender-vs.-receiver based congestion = control, because it's a seemingly simple problem for which we should be = able to agree on a clear answer?!

As most of you probably know by now, I'm critical of a receiver-based = approach as in RRTCC. (In fact, as I will explain further below, I argue = against a *combined* sender+receiver approach). Here is a plus/minus = list as I see it:


PLUS no. 1: it helps to reduce the amount of feedback. That's really the = ONLY benefit.

It also has a small = benefit in that it can more easily make use of new signals as they are = introduced, without having to modify the feedback message, but I guess = that argument is a bit = hypothetical.

Yes, I'd say that's = hypothetical  :-)   because at the end of the day, there's = only so much you can measure... has a packet made it or not, and how = long did it take. I argue for giving all of that information to the = sender if we go for a sender-based = approach.

 

MINUS no. 1: it requires the same mechanism on the sender and receiver = side, which means that, if RTP becomes a "framework" for congestion = control mechanisms, we must signal which mechanism is used to the other = side. In contrast, we don't have to do this with TCP's (implemented but = not standardized) pluggable congestion control. This is, to me, the = biggest problem, as it requires code updates to happen on both sides for = a new mechanism to be deployed.

MINUS no. 2: it could make combined congestion control between multiple = flows via the FSE more complicated. Anyway it seems we'll need an FSE on = the sender AND receiver side, but with receiver-based congestion = control, we'll face the question: for two flows between the same two = hosts, sharing the same bottleneck, should the receivers exchange = information and coordinate their feedback, or should the senders = exchange information and coordinate their behavior?  =3D> when = congestion control mechanisms are split across sender and receiver, the = right answer to this question becomes a per-mechanism decision.


Please amend this list if I'm missing something. Regarding the one PLUS = above, here's a critical look at the benefits of reducing feedback **via = receiver-side congestion control**:

- less feedback means a greater chance for the feedback to be dropped, = which translates into a greater chance for undesirable sender = behavior
- we deal with interactive traffic, in which case a lot of the feedback = could hopefully be piggybacked onto payload packets
- in some cases there will be other parallel flows (e.g. the data = channel in rtcweb) that already give us all the feedback that we need, = this is another chance for feedback reduction
- receiver-side-congestion-control-based feedback reduction as in RRTCC = means to reduce the feedback whenever feedback isn't urgent for the = sender. I'd argue that, in fact, we should reduce feedback only when the = channel carrying it (the backwards channel) is congested, and that is a = generic function, not bound to the sender-side congestion control = behavior.


So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver = Steeg wrote:

***
1- The upstream/return traffic is (generally) assumed to be a precious = resource by the RTP community. This is partially due to multicast = considerations (which we can mostly ignore here) and partially due to = asynchronous networks. Note that the CableTV community has found it = necessary to play games with TCP acks in Cable Modems because of = upstream bandwidth limitations, even for unicast TCP traffic. This is an = ugly hack that I will not defend here, but it is indicative of the = problem space. The net-net is that we have to be somewhat conservative = in our sending of acks, or we will end up in similar trouble.
***

As he states, multicast is out of scope. Plus, I think we should care = more about technical reasons than what the RTP community considers to be = a precious resource. As for the CableTV example, one can always find = examples where people started doing useless things  :-)   but = consider the following: many parallel TCP connections, each sending lots = of feedback, work okay for maaaany end users that 1) surf the Internet = or (bringing it closer to rtcweb thinking)  2) use P2P = applications. And TCP doesn't even do any form of congestion control on = ACKs (an RFC exists but noone uses it (so far)).

I'm not saying ACKs never cause problems. I'm saying it's probably rare = that they do, and reducing their number WHEN they cause trouble is good = enough (and, I would argue, a better decision).


Let's take a step back and summarize the situation:
1) congestion-control-based-feedback-reduction has at least one = significant MINUS (no. 1), probably two
2) the benefits of doing it seem minimal
3) not being based on congestion along the backwards path, it misses the = point somewhat...


As a result of the above, I would suggest to move all congestion control = functionality to the sender side and keep the receiver side dumb, as in = TCP, but amended with some generic (i.e. not mechanism-specific) = feedback-reduction functions (ACK congestion control; piggybacking; = omitting feedback when it is known (e.g. via a signal from the sender) = that we get feedback from another flow).

Alternatively, we could still remove the MINUS no. 1 above by agreeing = on a generic sender behavior. IIRC, in RRTCC, the sender is rather = simple - it follows the rate dictated by the receiver and has a timeout = behavior. If all congestion control mechanisms are installed on the = receiver side only, with the same agreed generic sender behavior for = everyone, we can also have pluggable congestion control without a need = for signalling.

I agree that if we go for a = receiver-based approach, the sender must be dumb. And the other way = around if we go for a sender-based = approach.

Great! Having one side = dumb is the most important thing here = IMO.


 

It's just the idea of multiple proposals for congestion control = involving newly described sender AND receiver behavior that strikes me = as bad design.

Thoughts?

One benefit I see with = having the intelligence at the sender is if you want to do something = more clever when probing the channel, which would require coordination = between the sender and the one who's supposed to come to some conclusion = from the incoming packets. I think Bill Ver Steeg touched upon something = along those lines:

"Basic senders will simply tell the = receiver to gather the data every N seconds and send it every N seconds = (plus when there are problems, as defined by the specification). More = sophisticated senders could drive more complex relationships, asking the = receiver to tabulate/send the data on demand in semi-real time. This = would allow a sophisticated sender to send a varying data patterns and = get the feedback they require, yet not require too much shared state = between the sender and receiver. As long as the receiver is a simple = state machine, I think we would be = OK."

That method = actually just becomes another entry in the list of feedback-reduction = mechanisms that we already have.

Here's an = updated summary:

1) I have argued that reducing = feedback really isn't all that important.
2) Say, we want to = do it (still a good thing, I think).
.. a) Then we can and = should, first of all, do it based on congestion on the backward = path.
.. b) Additionally, it might be possible to reduce = feedback because it can be piggybacked onto payload (as most scenarios = would have traffic flowing both ways).
.. c) Additionally, it = might be possible to exploit feedback from other parallel flows (e.g., = the data channel in rtcweb)
.. d) Additionally, we can do what = is written above, let the sender tell the receiver how much feedback it = needs.

All of this is possible with having the = logic on the sender side only, and having a dumb = receiver.

Cheers,
Michael
= --Apple-Mail=_755CF64E-2750-464C-9EEA-FE0642B56609-- From holmer@google.com Mon Sep 24 05:06:25 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED6121F862B for ; Mon, 24 Sep 2012 05:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1HITsbmKap6 for ; Mon, 24 Sep 2012 05:06:20 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5036521F8628 for ; Mon, 24 Sep 2012 05:06:20 -0700 (PDT) Received: by iec9 with SMTP id 9so11754160iec.31 for ; Mon, 24 Sep 2012 05:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=7fqtdj0m5T6J6XvceOaqeZjMp36wdJ0YgVVrGYrZeSU=; b=Ta1KJ01N5yhkkggtaT7M7k1FQ5WbBrwjR0COZGdevdkDrY3WVAojRG4WBrVF3OT2w6 CQ1lqWTaXhzQEi9JmML0AEG1cV+TpgnG7ZlssV+llzkxW3wIwVCy74dnnKCIjbomCz7v bevsfQuZITLdKkDmLN/OUR3GV2K3h8dqnMC/VD1lGMhSpnIKtdTLj/ZOv1xo07ExnDJN iFB9meqBY1P2Yo7Hm+04T3Bb0SJvHvfIBhZorx2RypRSwm4KfhZdoS22xWMKT3H+FKjH UZrlwzB5h7kZfgMzE10Mdrg1w361sH/eNbZ8fEPgD2Eq61Km9syTiNOBID+U1ThRHb9X oKGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=7fqtdj0m5T6J6XvceOaqeZjMp36wdJ0YgVVrGYrZeSU=; b=bc/ANpLqkQtFak95iHylO1HfXEKoXxMY9IVGCTyGqncg1rmAMYHOCcivIqESxDeCGo 6hl6yN/vIdh3byRyZb113D3sL1kR7LcLjWSbY8L9XnK4aCxjmMsM/wprWhXKFCNrWFoS wLhYQTtWUn5OTZaQV0htN7vVuyGFe478Z5W9zcuwHXQfg5ykjb4NdpER4xw8Ayip3We4 /AIHtd6RYRzCKHeCCWx6DWFQ7vrF8mpwLvm1Gu7n+sAeoLips4eNEwwNsUXZhBtnS+/p bFQ58dzU4LZsF3Sb8KV1ZxhieD2p+jG/C7vXRYfvklt0D039egM2YrrkaMgSxikFKH1d f3zA== Received: by 10.43.93.69 with SMTP id bt5mr9343307icc.8.1348488377212; Mon, 24 Sep 2012 05:06:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.93.69 with SMTP id bt5mr9343299icc.8.1348488377027; Mon, 24 Sep 2012 05:06:17 -0700 (PDT) Sender: holmer@google.com Received: by 10.50.237.103 with HTTP; Mon, 24 Sep 2012 05:06:16 -0700 (PDT) In-Reply-To: <392AA42E-3BFA-4991-B0E9-FA30F276E7D2@ifi.uio.no> References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <392AA42E-3BFA-4991-B0E9-FA30F276E7D2@ifi.uio.no> Date: Mon, 24 Sep 2012 14:06:16 +0200 X-Google-Sender-Auth: um8C-SEXbzM66IE_CaA1X1M_0_E Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=bcaec5186a52b24cf704ca716a44 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmJXKdny11WiKoeeLYQIXXF10KRaJzwN1DICGRTxJq2hc2tNhjD2UFCiBw4CFeaJMpM/sCkrQnrKBwI8Gv+QKXkCm431b1Z5V7OK9dOpjQNRvIbnvcfP7jS9re0sCsRal0sN1oBDhVA62tCMQ/y5dQH70gjYY+8CQqPLP7tpdm40LRkMeTTlC0EIOCo9Jpd/x7tBA+t Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 12:06:25 -0000 --bcaec5186a52b24cf704ca716a44 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 24, 2012 at 10:40 AM, Michael Welzl wrote: > Hi, > > Sorry, this answer is almost ridiculously late... > I compensate by being the first one to send a technical discussion message > to the new list :-) > > > On 21. sep. 2012, at 16:20, Stefan Holmer wrote: > > > On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl wrote: > >> Hi, >> >> Sorry for bringing this up yet again - but my thoughts just keep >> returning to the question of sender-vs.-receiver based congestion control, >> because it's a seemingly simple problem for which we should be able to >> agree on a clear answer?! >> >> As most of you probably know by now, I'm critical of a receiver-based >> approach as in RRTCC. (In fact, as I will explain further below, I argue >> against a *combined* sender+receiver approach). Here is a plus/minus list >> as I see it: >> >> >> PLUS no. 1: it helps to reduce the amount of feedback. That's really the >> ONLY benefit. >> > > It also has a small benefit in that it can more easily make use of new > signals as they are introduced, without having to modify the feedback > message, but I guess that argument is a bit hypothetical. > > > Yes, I'd say that's hypothetical :-) because at the end of the day, > there's only so much you can measure... has a packet made it or not, and > how long did it take. I argue for giving all of that information to the > sender if we go for a sender-based approach. > > > > >> MINUS no. 1: it requires the same mechanism on the sender and receiver >> side, which means that, if RTP becomes a "framework" for congestion control >> mechanisms, we must signal which mechanism is used to the other side. In >> contrast, we don't have to do this with TCP's (implemented but not >> standardized) pluggable congestion control. This is, to me, the biggest >> problem, as it requires code updates to happen on both sides for a new >> mechanism to be deployed. >> >> MINUS no. 2: it could make combined congestion control between multiple >> flows via the FSE more complicated. Anyway it seems we'll need an FSE on >> the sender AND receiver side, but with receiver-based congestion control, >> we'll face the question: for two flows between the same two hosts, sharing >> the same bottleneck, should the receivers exchange information and >> coordinate their feedback, or should the senders exchange information and >> coordinate their behavior? => when congestion control mechanisms are split >> across sender and receiver, the right answer to this question becomes a >> per-mechanism decision. >> >> >> Please amend this list if I'm missing something. Regarding the one PLUS >> above, here's a critical look at the benefits of reducing feedback **via >> receiver-side congestion control**: >> >> - less feedback means a greater chance for the feedback to be dropped, >> which translates into a greater chance for undesirable sender behavior >> - we deal with interactive traffic, in which case a lot of the feedback >> could hopefully be piggybacked onto payload packets >> - in some cases there will be other parallel flows (e.g. the data channel >> in rtcweb) that already give us all the feedback that we need, this is >> another chance for feedback reduction >> - receiver-side-congestion-control-based feedback reduction as in RRTCC >> means to reduce the feedback whenever feedback isn't urgent for the sender. >> I'd argue that, in fact, we should reduce feedback only when the channel >> carrying it (the backwards channel) is congested, and that is a generic >> function, not bound to the sender-side congestion control behavior. >> >> >> So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver >> Steeg wrote: >> >> *** >> 1- The upstream/return traffic is (generally) assumed to be a precious >> resource by the RTP community. This is partially due to multicast >> considerations (which we can mostly ignore here) and partially due to >> asynchronous networks. Note that the CableTV community has found it >> necessary to play games with TCP acks in Cable Modems because of upstream >> bandwidth limitations, even for unicast TCP traffic. This is an ugly hack >> that I will not defend here, but it is indicative of the problem space. The >> net-net is that we have to be somewhat conservative in our sending of acks, >> or we will end up in similar trouble. >> *** >> >> As he states, multicast is out of scope. Plus, I think we should care >> more about technical reasons than what the RTP community considers to be a >> precious resource. As for the CableTV example, one can always find examples >> where people started doing useless things :-) but consider the >> following: many parallel TCP connections, each sending lots of feedback, >> work okay for maaaany end users that 1) surf the Internet or (bringing it >> closer to rtcweb thinking) 2) use P2P applications. And TCP doesn't even >> do any form of congestion control on ACKs (an RFC exists but noone uses it >> (so far)). >> >> I'm not saying ACKs never cause problems. I'm saying it's probably rare >> that they do, and reducing their number WHEN they cause trouble is good >> enough (and, I would argue, a better decision). >> >> >> Let's take a step back and summarize the situation: >> 1) congestion-control-based-feedback-reduction has at least one >> significant MINUS (no. 1), probably two >> 2) the benefits of doing it seem minimal >> 3) not being based on congestion along the backwards path, it misses the >> point somewhat... >> >> >> As a result of the above, I would suggest to move all congestion control >> functionality to the sender side and keep the receiver side dumb, as in >> TCP, but amended with some generic (i.e. not mechanism-specific) >> feedback-reduction functions (ACK congestion control; piggybacking; >> omitting feedback when it is known (e.g. via a signal from the sender) that >> we get feedback from another flow). >> >> Alternatively, we could still remove the MINUS no. 1 above by agreeing on >> a generic sender behavior. IIRC, in RRTCC, the sender is rather simple - it >> follows the rate dictated by the receiver and has a timeout behavior. If >> all congestion control mechanisms are installed on the receiver side only, >> with the same agreed generic sender behavior for everyone, we can also have >> pluggable congestion control without a need for signalling. >> > > I agree that if we go for a receiver-based approach, the sender must be > dumb. And the other way around if we go for a sender-based approach. > > > Great! Having one side dumb is the most important thing here IMO. > > > > >> >> It's just the idea of multiple proposals for congestion control involving >> newly described sender AND receiver behavior that strikes me as bad design. >> >> Thoughts? >> > > One benefit I see with having the intelligence at the sender is if you > want to do something more clever when probing the channel, which would > require coordination between the sender and the one who's supposed to come > to some conclusion from the incoming packets. I think Bill Ver Steeg > touched upon something along those lines: > > "Basic senders will simply tell the receiver to gather the data every N > seconds and send it every N seconds (plus when there are problems, as > defined by the specification). More sophisticated senders could drive more > complex relationships, asking the receiver to tabulate/send the data on > demand in semi-real time. This would allow a sophisticated sender to send a > varying data patterns and get the feedback they require, yet not require > too much shared state between the sender and receiver. As long as the > receiver is a simple state machine, I think we would be OK." > > > That method actually just becomes another entry in the list of > feedback-reduction mechanisms that we already have. > > Here's an updated summary: > > 1) I have argued that reducing feedback really isn't all that important. > 2) Say, we want to do it (still a good thing, I think). > .. a) Then we can and should, first of all, do it based on congestion on > the backward path. > .. b) Additionally, it might be possible to reduce feedback because it can > be piggybacked onto payload (as most scenarios would have traffic flowing > both ways). > .. c) Additionally, it might be possible to exploit feedback from other > parallel flows (e.g., the data channel in rtcweb) > .. d) Additionally, we can do what is written above, let the sender tell > the receiver how much feedback it needs. > Yes, however, if we have a feedback message per packet the sender will always have all the feedback it needs. What I was thinking of was that if the implementation wants to do something clever by sending packets in some pattern, knowledge about that clever thing must be available both at the sender and the receiver if we limit the feedback to, for instance, a bitrate. If we add a way for the sender to ask for more feedback then that would allow for the sender to do this kind of cleverness also in the receiver-based approach. And it doesn't have to be decided in advance what that cleverness is. > > All of this is possible with having the logic on the sender side only, and > having a dumb receiver. > > Cheers, > Michael > > --bcaec5186a52b24cf704ca716a44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 24, 2012 at 10:40 AM, Michae= l Welzl <michawe@ifi.uio.no> wrote:
Hi,

Sorry, this answ= er is almost ridiculously late...
I compensate by being the first= one to send a technical discussion message to the new list =A0:-)


On 21. sep. 2012, at 16:20, = Stefan Holmer wrote:


On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl <michawe@ifi.u= io.no> wrote:
Hi,

Sorry for bringing this up yet again - but my thoughts just keep returning = to the question of sender-vs.-receiver based congestion control, because it= 's a seemingly simple problem for which we should be able to agree on a= clear answer?!

As most of you probably know by now, I'm critical of a receiver-based a= pproach as in RRTCC. (In fact, as I will explain further below, I argue aga= inst a *combined* sender+receiver approach). Here is a plus/minus list as I= see it:


PLUS no. 1: it helps to reduce the amount of feedback. That's really th= e ONLY benefit.

It also has a small ben= efit in that it can more easily make use of new signals as they are introdu= ced, without having to modify the feedback message, but I guess that argume= nt is a bit hypothetical.

Yes, I'd say that's hypothe= tical =A0:-) =A0 because at the end of the day, there's only so much yo= u can measure... has a packet made it or not, and how long did it take. I a= rgue for giving all of that information to the sender if we go for a sender= -based approach.

=A0

MINUS no. 1: it requires the same mechanism on the sender and receiver side= , which means that, if RTP becomes a "framework" for congestion c= ontrol mechanisms, we must signal which mechanism is used to the other side= . In contrast, we don't have to do this with TCP's (implemented but= not standardized) pluggable congestion control. This is, to me, the bigges= t problem, as it requires code updates to happen on both sides for a new me= chanism to be deployed.

MINUS no. 2: it could make combined congestion control between multiple flo= ws via the FSE more complicated. Anyway it seems we'll need an FSE on t= he sender AND receiver side, but with receiver-based congestion control, we= 'll face the question: for two flows between the same two hosts, sharin= g the same bottleneck, should the receivers exchange information and coordi= nate their feedback, or should the senders exchange information and coordin= ate their behavior? =A0=3D> when congestion control mechanisms are split= across sender and receiver, the right answer to this question becomes a pe= r-mechanism decision.


Please amend this list if I'm missing something. Regarding the one PLUS= above, here's a critical look at the benefits of reducing feedback **v= ia receiver-side congestion control**:

- less feedback means a greater chance for the feedback to be dropped, whic= h translates into a greater chance for undesirable sender behavior
- we deal with interactive traffic, in which case a lot of the feedback cou= ld hopefully be piggybacked onto payload packets
- in some cases there will be other parallel flows (e.g. the data channel i= n rtcweb) that already give us all the feedback that we need, this is anoth= er chance for feedback reduction
- receiver-side-congestion-control-based feedback reduction as in RRTCC mea= ns to reduce the feedback whenever feedback isn't urgent for the sender= . I'd argue that, in fact, we should reduce feedback only when the chan= nel carrying it (the backwards channel) is congested, and that is a generic= function, not bound to the sender-side congestion control behavior.


So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver Ste= eg wrote:

***
1- The upstream/return traffic is (generally) assumed to be a precious reso= urce by the RTP community. This is partially due to multicast consideration= s (which we can mostly ignore here) and partially due to asynchronous netwo= rks. Note that the CableTV community has found it necessary to play games w= ith TCP acks in Cable Modems because of upstream bandwidth limitations, eve= n for unicast TCP traffic. This is an ugly hack that I will not defend here= , but it is indicative of the problem space. The net-net is that we have to= be somewhat conservative in our sending of acks, or we will end up in simi= lar trouble.
***

As he states, multicast is out of scope. Plus, I think we should care more = about technical reasons than what the RTP community considers to be a preci= ous resource. As for the CableTV example, one can always find examples wher= e people started doing useless things =A0:-) =A0 but consider the following= : many parallel TCP connections, each sending lots of feedback, work okay f= or maaaany end users that 1) surf the Internet or (bringing it closer to rt= cweb thinking) =A02) use P2P applications. And TCP doesn't even do any = form of congestion control on ACKs (an RFC exists but noone uses it (so far= )).

I'm not saying ACKs never cause problems. I'm saying it's proba= bly rare that they do, and reducing their number WHEN they cause trouble is= good enough (and, I would argue, a better decision).


Let's take a step back and summarize the situation:
1) congestion-control-based-feedback-reduction has at least one significant= MINUS (no. 1), probably two
2) the benefits of doing it seem minimal
3) not being based on congestion along the backwards path, it misses the po= int somewhat...


As a result of the above, I would suggest to move all congestion control fu= nctionality to the sender side and keep the receiver side dumb, as in TCP, = but amended with some generic (i.e. not mechanism-specific) feedback-reduct= ion functions (ACK congestion control; piggybacking; omitting feedback when= it is known (e.g. via a signal from the sender) that we get feedback from = another flow).

Alternatively, we could still remove the MINUS no. 1 above by agreeing on a= generic sender behavior. IIRC, in RRTCC, the sender is rather simple - it = follows the rate dictated by the receiver and has a timeout behavior. If al= l congestion control mechanisms are installed on the receiver side only, wi= th the same agreed generic sender behavior for everyone, we can also have p= luggable congestion control without a need for signalling.

I agree that if we go for a receiver-based= approach, the sender must be dumb. And the other way around if we go for a= sender-based approach.

Great!= Having one side dumb is the most important thing here IMO.


=A0

It's just the idea of multiple proposals for congestion control involvi= ng newly described sender AND receiver behavior that strikes me as bad desi= gn.

Thoughts?

One benefit I see with having= the intelligence at the sender is if you want to do something more clever = when probing the channel, which would require coordination between the send= er and the one who's supposed to come to some conclusion from the incom= ing packets. I think Bill Ver Steeg touched upon something along those line= s:

"Basic senders will simply tell the receiver = to gather the data every N seconds and send it every N seconds (plus when t= here are problems, as defined by the specification). More sophisticated sen= ders could drive more complex relationships, asking the receiver to tabulat= e/send the data on demand in semi-real time. This would allow a sophisticat= ed sender to send a varying data patterns and get the feedback they require= , yet not require too much shared state between the sender and receiver. As= long as the receiver is a simple state machine, I think we would be OK.&qu= ot;

That method actually just beco= mes another entry in the list of feedback-reduction mechanisms that we alre= ady have.

Here's an updated summary:

1) I have argued that reducing feedback really isn'= t all that important.
2) Say, we want to do it (still a good thin= g, I think).
.. a) Then we can and should, first of all, do it ba= sed on congestion on the backward path.
.. b) Additionally, it might be possible to reduce feedback because it= can be piggybacked onto payload (as most scenarios would have traffic flow= ing both ways).
.. c) Additionally, it might be possible to explo= it feedback from other parallel flows (e.g., the data channel in rtcweb)
.. d) Additionally, we can do what is written above, let the sender te= ll the receiver how much feedback it needs.

Yes, however, if we have a feedback message per pa= cket the sender will always have all the feedback it needs. What I was thin= king of was that if the implementation wants to do something clever by send= ing packets in some pattern, knowledge about that clever thing must be avai= lable both at the sender and the receiver if we limit the feedback to, for = instance, a bitrate.

If we add a way for the sender to ask for more feedback= then that would allow for the sender to do this kind of cleverness also in= the receiver-based approach. And it doesn't have to be decided in adva= nce what that cleverness is.
=A0

All of this is possible with having the= logic on the sender side only, and having a dumb receiver.

Cheers,
Michael


--bcaec5186a52b24cf704ca716a44-- From michawe@ifi.uio.no Mon Sep 24 05:56:25 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC421F866E for ; Mon, 24 Sep 2012 05:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCNrmdCt1k1p for ; Mon, 24 Sep 2012 05:56:23 -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 875EB21F8679 for ; Mon, 24 Sep 2012 05:56:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TG8Cz-0001x7-73; Mon, 24 Sep 2012 14:56:21 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TG8Cy-0000wp-5I; Mon, 24 Sep 2012 14:56:21 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_F32365F4-0108-499E-A24C-00264ABB5F1E" From: Michael Welzl In-Reply-To: Date: Mon, 24 Sep 2012 14:56:18 +0200 Message-Id: References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <392AA42E-3BFA-4991-B0E9-FA30F276E7D2@ifi.uio.no> To: Stefan Holmer X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 13 sum msgs/h 6 total rcpts 24011 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.918, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 57C8C44B508B0226D2A5B3833597982D2C4748D4 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9672 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 12:56:25 -0000 --Apple-Mail=_F32365F4-0108-499E-A24C-00264ABB5F1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 24. sep. 2012, at 14:06, Stefan Holmer wrote: >=20 >=20 > On Mon, Sep 24, 2012 at 10:40 AM, Michael Welzl = wrote: > Hi, >=20 > Sorry, this answer is almost ridiculously late... > I compensate by being the first one to send a technical discussion = message to the new list :-) >=20 >=20 > On 21. sep. 2012, at 16:20, Stefan Holmer wrote: >=20 >>=20 >> On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl = wrote: >> Hi, >>=20 >> Sorry for bringing this up yet again - but my thoughts just keep = returning to the question of sender-vs.-receiver based congestion = control, because it's a seemingly simple problem for which we should be = able to agree on a clear answer?! >>=20 >> As most of you probably know by now, I'm critical of a receiver-based = approach as in RRTCC. (In fact, as I will explain further below, I argue = against a *combined* sender+receiver approach). Here is a plus/minus = list as I see it: >>=20 >>=20 >> PLUS no. 1: it helps to reduce the amount of feedback. That's really = the ONLY benefit. >>=20 >> It also has a small benefit in that it can more easily make use of = new signals as they are introduced, without having to modify the = feedback message, but I guess that argument is a bit hypothetical. >=20 > Yes, I'd say that's hypothetical :-) because at the end of the day, = there's only so much you can measure... has a packet made it or not, and = how long did it take. I argue for giving all of that information to the = sender if we go for a sender-based approach. >=20 > =20 >>=20 >> MINUS no. 1: it requires the same mechanism on the sender and = receiver side, which means that, if RTP becomes a "framework" for = congestion control mechanisms, we must signal which mechanism is used to = the other side. In contrast, we don't have to do this with TCP's = (implemented but not standardized) pluggable congestion control. This = is, to me, the biggest problem, as it requires code updates to happen on = both sides for a new mechanism to be deployed. >>=20 >> MINUS no. 2: it could make combined congestion control between = multiple flows via the FSE more complicated. Anyway it seems we'll need = an FSE on the sender AND receiver side, but with receiver-based = congestion control, we'll face the question: for two flows between the = same two hosts, sharing the same bottleneck, should the receivers = exchange information and coordinate their feedback, or should the = senders exchange information and coordinate their behavior? =3D> when = congestion control mechanisms are split across sender and receiver, the = right answer to this question becomes a per-mechanism decision. >>=20 >>=20 >> Please amend this list if I'm missing something. Regarding the one = PLUS above, here's a critical look at the benefits of reducing feedback = **via receiver-side congestion control**: >>=20 >> - less feedback means a greater chance for the feedback to be = dropped, which translates into a greater chance for undesirable sender = behavior >> - we deal with interactive traffic, in which case a lot of the = feedback could hopefully be piggybacked onto payload packets >> - in some cases there will be other parallel flows (e.g. the data = channel in rtcweb) that already give us all the feedback that we need, = this is another chance for feedback reduction >> - receiver-side-congestion-control-based feedback reduction as in = RRTCC means to reduce the feedback whenever feedback isn't urgent for = the sender. I'd argue that, in fact, we should reduce feedback only when = the channel carrying it (the backwards channel) is congested, and that = is a generic function, not bound to the sender-side congestion control = behavior. >>=20 >>=20 >> So how urgent is it to reduce feedback, anyway? Some time ago, Bill = Ver Steeg wrote: >>=20 >> *** >> 1- The upstream/return traffic is (generally) assumed to be a = precious resource by the RTP community. This is partially due to = multicast considerations (which we can mostly ignore here) and partially = due to asynchronous networks. Note that the CableTV community has found = it necessary to play games with TCP acks in Cable Modems because of = upstream bandwidth limitations, even for unicast TCP traffic. This is an = ugly hack that I will not defend here, but it is indicative of the = problem space. The net-net is that we have to be somewhat conservative = in our sending of acks, or we will end up in similar trouble. >> *** >>=20 >> As he states, multicast is out of scope. Plus, I think we should care = more about technical reasons than what the RTP community considers to be = a precious resource. As for the CableTV example, one can always find = examples where people started doing useless things :-) but consider = the following: many parallel TCP connections, each sending lots of = feedback, work okay for maaaany end users that 1) surf the Internet or = (bringing it closer to rtcweb thinking) 2) use P2P applications. And = TCP doesn't even do any form of congestion control on ACKs (an RFC = exists but noone uses it (so far)). >>=20 >> I'm not saying ACKs never cause problems. I'm saying it's probably = rare that they do, and reducing their number WHEN they cause trouble is = good enough (and, I would argue, a better decision). >>=20 >>=20 >> Let's take a step back and summarize the situation: >> 1) congestion-control-based-feedback-reduction has at least one = significant MINUS (no. 1), probably two >> 2) the benefits of doing it seem minimal >> 3) not being based on congestion along the backwards path, it misses = the point somewhat... >>=20 >>=20 >> As a result of the above, I would suggest to move all congestion = control functionality to the sender side and keep the receiver side = dumb, as in TCP, but amended with some generic (i.e. not = mechanism-specific) feedback-reduction functions (ACK congestion = control; piggybacking; omitting feedback when it is known (e.g. via a = signal from the sender) that we get feedback from another flow). >>=20 >> Alternatively, we could still remove the MINUS no. 1 above by = agreeing on a generic sender behavior. IIRC, in RRTCC, the sender is = rather simple - it follows the rate dictated by the receiver and has a = timeout behavior. If all congestion control mechanisms are installed on = the receiver side only, with the same agreed generic sender behavior for = everyone, we can also have pluggable congestion control without a need = for signalling. >>=20 >> I agree that if we go for a receiver-based approach, the sender must = be dumb. And the other way around if we go for a sender-based approach. >=20 > Great! Having one side dumb is the most important thing here IMO. >=20 >=20 >> =20 >>=20 >> It's just the idea of multiple proposals for congestion control = involving newly described sender AND receiver behavior that strikes me = as bad design. >>=20 >> Thoughts? >>=20 >> One benefit I see with having the intelligence at the sender is if = you want to do something more clever when probing the channel, which = would require coordination between the sender and the one who's supposed = to come to some conclusion from the incoming packets. I think Bill Ver = Steeg touched upon something along those lines: >>=20 >> "Basic senders will simply tell the receiver to gather the data every = N seconds and send it every N seconds (plus when there are problems, as = defined by the specification). More sophisticated senders could drive = more complex relationships, asking the receiver to tabulate/send the = data on demand in semi-real time. This would allow a sophisticated = sender to send a varying data patterns and get the feedback they = require, yet not require too much shared state between the sender and = receiver. As long as the receiver is a simple state machine, I think we = would be OK." >=20 > That method actually just becomes another entry in the list of = feedback-reduction mechanisms that we already have. >=20 > Here's an updated summary: >=20 > 1) I have argued that reducing feedback really isn't all that = important. > 2) Say, we want to do it (still a good thing, I think). > .. a) Then we can and should, first of all, do it based on congestion = on the backward path. > .. b) Additionally, it might be possible to reduce feedback because it = can be piggybacked onto payload (as most scenarios would have traffic = flowing both ways). > .. c) Additionally, it might be possible to exploit feedback from = other parallel flows (e.g., the data channel in rtcweb) > .. d) Additionally, we can do what is written above, let the sender = tell the receiver how much feedback it needs. >=20 > Yes, however, if we have a feedback message per packet the sender will = always have all the feedback it needs. What I was thinking of was that = if the implementation wants to do something clever by sending packets in = some pattern, knowledge about that clever thing must be available both = at the sender and the receiver if we limit the feedback to, for = instance, a bitrate. >=20 > If we add a way for the sender to ask for more feedback then that = would allow for the sender to do this kind of cleverness also in the = receiver-based approach. And it doesn't have to be decided in advance = what that cleverness is. Maybe I'm not fully getting your idea, but somehow this all sounds like = making things unnecessarily complicated. Knowing whether the congestion = control mechanism requires more feedback or not seems to me to miss the = problem that we're trying to solve. What's the point of reducing feedback when there's no congestion on the = backward path anyway? The less feedback we send, the more risk of a = message being lost due to whatever reason (congestion appearing, link = noise, ...), and the more fragile the whole thing becomes. I would = therefore argue for sending tons of feedback when we can, and only = reduce when we must. And then, in the face of backwards congestion, we = really MUST - the data congestion control mechanism (I say "data" to = distinguish from ACK congestion control) will just have to cope with it. = So it's probably not even useful to know how much feedback we ideally = need... Cheers, Michael --Apple-Mail=_F32365F4-0108-499E-A24C-00264ABB5F1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On Mon, Sep 24, 2012 at = 10:40 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:
Hi,

Sorry, this = answer is almost ridiculously late...
I compensate by being = the first one to send a technical discussion message to the new list =  :-)


On 21. sep. 2012, at = 16:20, Stefan Holmer wrote:


On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl = <michawe@ifi.uio.no> wrote:
Hi,

Sorry for bringing this up yet again - but my thoughts just keep = returning to the question of sender-vs.-receiver based congestion = control, because it's a seemingly simple problem for which we should be = able to agree on a clear answer?!

As most of you probably know by now, I'm critical of a receiver-based = approach as in RRTCC. (In fact, as I will explain further below, I argue = against a *combined* sender+receiver approach). Here is a plus/minus = list as I see it:


PLUS no. 1: it helps to reduce the amount of feedback. That's really the = ONLY benefit.

It also has a small = benefit in that it can more easily make use of new signals as they are = introduced, without having to modify the feedback message, but I guess = that argument is a bit hypothetical.

Yes, I'd say that's hypothetical =  :-)   because at the end of the day, there's only so much you = can measure... has a packet made it or not, and how long did it take. I = argue for giving all of that information to the sender if we go for a = sender-based approach.

 

MINUS no. 1: it requires the same mechanism on the sender and receiver = side, which means that, if RTP becomes a "framework" for congestion = control mechanisms, we must signal which mechanism is used to the other = side. In contrast, we don't have to do this with TCP's (implemented but = not standardized) pluggable congestion control. This is, to me, the = biggest problem, as it requires code updates to happen on both sides for = a new mechanism to be deployed.

MINUS no. 2: it could make combined congestion control between multiple = flows via the FSE more complicated. Anyway it seems we'll need an FSE on = the sender AND receiver side, but with receiver-based congestion = control, we'll face the question: for two flows between the same two = hosts, sharing the same bottleneck, should the receivers exchange = information and coordinate their feedback, or should the senders = exchange information and coordinate their behavior?  =3D> when = congestion control mechanisms are split across sender and receiver, the = right answer to this question becomes a per-mechanism decision.


Please amend this list if I'm missing something. Regarding the one PLUS = above, here's a critical look at the benefits of reducing feedback **via = receiver-side congestion control**:

- less feedback means a greater chance for the feedback to be dropped, = which translates into a greater chance for undesirable sender = behavior
- we deal with interactive traffic, in which case a lot of the feedback = could hopefully be piggybacked onto payload packets
- in some cases there will be other parallel flows (e.g. the data = channel in rtcweb) that already give us all the feedback that we need, = this is another chance for feedback reduction
- receiver-side-congestion-control-based feedback reduction as in RRTCC = means to reduce the feedback whenever feedback isn't urgent for the = sender. I'd argue that, in fact, we should reduce feedback only when the = channel carrying it (the backwards channel) is congested, and that is a = generic function, not bound to the sender-side congestion control = behavior.


So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver = Steeg wrote:

***
1- The upstream/return traffic is (generally) assumed to be a precious = resource by the RTP community. This is partially due to multicast = considerations (which we can mostly ignore here) and partially due to = asynchronous networks. Note that the CableTV community has found it = necessary to play games with TCP acks in Cable Modems because of = upstream bandwidth limitations, even for unicast TCP traffic. This is an = ugly hack that I will not defend here, but it is indicative of the = problem space. The net-net is that we have to be somewhat conservative = in our sending of acks, or we will end up in similar trouble.
***

As he states, multicast is out of scope. Plus, I think we should care = more about technical reasons than what the RTP community considers to be = a precious resource. As for the CableTV example, one can always find = examples where people started doing useless things  :-)   but = consider the following: many parallel TCP connections, each sending lots = of feedback, work okay for maaaany end users that 1) surf the Internet = or (bringing it closer to rtcweb thinking)  2) use P2P = applications. And TCP doesn't even do any form of congestion control on = ACKs (an RFC exists but noone uses it (so far)).

I'm not saying ACKs never cause problems. I'm saying it's probably rare = that they do, and reducing their number WHEN they cause trouble is good = enough (and, I would argue, a better decision).


Let's take a step back and summarize the situation:
1) congestion-control-based-feedback-reduction has at least one = significant MINUS (no. 1), probably two
2) the benefits of doing it seem minimal
3) not being based on congestion along the backwards path, it misses the = point somewhat...


As a result of the above, I would suggest to move all congestion control = functionality to the sender side and keep the receiver side dumb, as in = TCP, but amended with some generic (i.e. not mechanism-specific) = feedback-reduction functions (ACK congestion control; piggybacking; = omitting feedback when it is known (e.g. via a signal from the sender) = that we get feedback from another flow).

Alternatively, we could still remove the MINUS no. 1 above by agreeing = on a generic sender behavior. IIRC, in RRTCC, the sender is rather = simple - it follows the rate dictated by the receiver and has a timeout = behavior. If all congestion control mechanisms are installed on the = receiver side only, with the same agreed generic sender behavior for = everyone, we can also have pluggable congestion control without a need = for signalling.

I agree that if we go for a = receiver-based approach, the sender must be dumb. And the other way = around if we go for a sender-based = approach.

Great! Having one = side dumb is the most important thing here IMO.


 

It's just the idea of multiple proposals for congestion control = involving newly described sender AND receiver behavior that strikes me = as bad design.

Thoughts?

One benefit I see with = having the intelligence at the sender is if you want to do something = more clever when probing the channel, which would require coordination = between the sender and the one who's supposed to come to some conclusion = from the incoming packets. I think Bill Ver Steeg touched upon something = along those lines:

"= Basic senders will simply tell the receiver to gather the data every N = seconds and send it every N seconds (plus when there are problems, as = defined by the specification). More sophisticated senders could drive = more complex relationships, asking the receiver to tabulate/send the = data on demand in semi-real time. This would allow a sophisticated = sender to send a varying data patterns and get the feedback they = require, yet not require too much shared state between the sender and = receiver. As long as the receiver is a simple state machine, I think we = would be OK."

That method actually just = becomes another entry in the list of feedback-reduction mechanisms that = we already have.

Here's an updated = summary:

1) I have argued that reducing feedback really isn't = all that important.
2) Say, we want to do it (still a good = thing, I think).
.. a) Then we can and should, first of all, = do it based on congestion on the backward path.
.. b) Additionally, it might be possible to reduce feedback because = it can be piggybacked onto payload (as most scenarios would have traffic = flowing both ways).
.. c) Additionally, it might be possible = to exploit feedback from other parallel flows (e.g., the data channel in = rtcweb)
.. d) Additionally, we can do what is written above, let the sender = tell the receiver how much feedback it = needs.

Yes, = however, if we have a feedback message per packet the sender will always = have all the feedback it needs. What I was thinking of was that if the = implementation wants to do something clever by sending packets in some = pattern, knowledge about that clever thing must be available both at the = sender and the receiver if we limit the feedback to, for instance, a = bitrate.

If we add a way for the sender to ask for more = feedback then that would allow for the sender to do this kind of = cleverness also in the receiver-based approach. And it doesn't have to = be decided in advance what that cleverness = is.

Maybe I'm not fully getting = your idea, but somehow this all sounds like making things unnecessarily = complicated. Knowing whether the congestion control mechanism requires = more feedback or not seems to me to miss the problem that we're trying = to solve.

What's the point of reducing feedback = when there's no congestion on the backward path anyway? The less = feedback we send, the more risk of a message being lost due to whatever = reason (congestion appearing, link noise, ...), and the more fragile the = whole thing becomes. I would therefore argue for sending tons of = feedback when we can, and only reduce when we must. And then, in the = face of backwards congestion, we really MUST - the data congestion = control mechanism (I say "data" to distinguish from ACK congestion = control) will just have to cope with it. So it's probably not even = useful to know how much feedback we ideally = need...

Cheers,
Michael

<= /div>= --Apple-Mail=_F32365F4-0108-499E-A24C-00264ABB5F1E-- From holmer@google.com Mon Sep 24 06:05:23 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8990C21F86B5 for ; Mon, 24 Sep 2012 06:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnWriFeJDdz8 for ; Mon, 24 Sep 2012 06:05:21 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBB821F86AB for ; Mon, 24 Sep 2012 06:05:21 -0700 (PDT) Received: by iec9 with SMTP id 9so11917361iec.31 for ; Mon, 24 Sep 2012 06:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=6Shi4Av9idggUKymJYzyM3/q5q2EykjTRAIvayY2Ol8=; b=EIh1x8lj7AXJXosvSIR1pOs6MTy6XIOI/Bhz/0IPAxzeNTlAbgk5khc5ye0Xh6vk8w AzI/lVhKBR2dh2G6vW2+jGxguqLESYzwHklCvWrF2TxH5fGowylaQv4qae/IA6946ob8 cSJCfMxBCfinDIR7j+hl9wZPvUPAjTxjoKqG1Wq/ikRXGp/BQWudMGuA4zsaN+Z/3Kod btT92umJNM7Xaox0Qwd1DdxLF42KJ+QvItyEfKAV34YmHv5joTSataPhsGmKZNWevEaz qrdz51RM1TeK0iqdCg++XP+YLI7u4LVfuzekLmfYfyfdX72IvxC6fbsPeD8StdB6EGbQ P/Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=6Shi4Av9idggUKymJYzyM3/q5q2EykjTRAIvayY2Ol8=; b=L/41eMdNW4jtUVWcLHg+ZUAj3DPhqrpCidpSP+QvTVJpy65yh/TXPvjva/JrYNJRBh P8dpTLV+91dkX2uTZ/T1e6qsaxmoPDK3s0nCVegApQtJJR2B7DMjbcEttfdEWre9MYLT e8DljrEIxEmwg0GcfOh8b1ljE6shLkqaGutxCzt+2/yYKDBxEfSwsIiDfw7m5enj3HDG S0BfTK8xLAI0JBIREWZ9F0KxRRD0xoJxHdrn7+hdpAQP4skNMk29Caz6iWtgQY+tFyYU qz1g/PjnqT5imh7POHc1nmImt4nPUG67XlzFoGdISJCdkLAV79AYo90WqmLSrLYDWnaO LuUw== Received: by 10.50.182.234 with SMTP id eh10mr2282659igc.32.1348491920994; Mon, 24 Sep 2012 06:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.182.234 with SMTP id eh10mr2282646igc.32.1348491920723; Mon, 24 Sep 2012 06:05:20 -0700 (PDT) Sender: holmer@google.com Received: by 10.50.237.103 with HTTP; Mon, 24 Sep 2012 06:05:20 -0700 (PDT) In-Reply-To: References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <392AA42E-3BFA-4991-B0E9-FA30F276E7D2@ifi.uio.no> Date: Mon, 24 Sep 2012 15:05:20 +0200 X-Google-Sender-Auth: IVuKnjUb-5-zk-etLR78YdVq8g0 Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=14dae9340ae9eace6904ca723dce X-System-Of-Record: true X-Gm-Message-State: ALoCoQmo0Try5O6GtBtF643F7n4mC/YnOOx/SWNntNksTIaQRORmnhqKevH8wuUVAg4XBPLeezMpcQv9xlMdjdrYLjdTwFQzcL/rHLaCBpRV8pPaCCf9au6+pjIRaHPEjGPuito1hLaOqn5GHhTHKcYGzBingJxUNI1X1hVtQe4anVEp4MAXYuuPT8CVW5OnxnavuaHtSix2 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 13:05:23 -0000 --14dae9340ae9eace6904ca723dce Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 24, 2012 at 2:56 PM, Michael Welzl wrote: > > On 24. sep. 2012, at 14:06, Stefan Holmer wrote: > > > > On Mon, Sep 24, 2012 at 10:40 AM, Michael Welzl wrote: > >> Hi, >> >> Sorry, this answer is almost ridiculously late... >> I compensate by being the first one to send a technical discussion >> message to the new list :-) >> >> >> On 21. sep. 2012, at 16:20, Stefan Holmer wrote: >> >> >> On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl wrote: >> >>> Hi, >>> >>> Sorry for bringing this up yet again - but my thoughts just keep >>> returning to the question of sender-vs.-receiver based congestion control, >>> because it's a seemingly simple problem for which we should be able to >>> agree on a clear answer?! >>> >>> As most of you probably know by now, I'm critical of a receiver-based >>> approach as in RRTCC. (In fact, as I will explain further below, I argue >>> against a *combined* sender+receiver approach). Here is a plus/minus list >>> as I see it: >>> >>> >>> PLUS no. 1: it helps to reduce the amount of feedback. That's really the >>> ONLY benefit. >>> >> >> It also has a small benefit in that it can more easily make use of new >> signals as they are introduced, without having to modify the feedback >> message, but I guess that argument is a bit hypothetical. >> >> >> Yes, I'd say that's hypothetical :-) because at the end of the day, >> there's only so much you can measure... has a packet made it or not, and >> how long did it take. I argue for giving all of that information to the >> sender if we go for a sender-based approach. >> >> >> >> >>> MINUS no. 1: it requires the same mechanism on the sender and receiver >>> side, which means that, if RTP becomes a "framework" for congestion control >>> mechanisms, we must signal which mechanism is used to the other side. In >>> contrast, we don't have to do this with TCP's (implemented but not >>> standardized) pluggable congestion control. This is, to me, the biggest >>> problem, as it requires code updates to happen on both sides for a new >>> mechanism to be deployed. >>> >>> MINUS no. 2: it could make combined congestion control between multiple >>> flows via the FSE more complicated. Anyway it seems we'll need an FSE on >>> the sender AND receiver side, but with receiver-based congestion control, >>> we'll face the question: for two flows between the same two hosts, sharing >>> the same bottleneck, should the receivers exchange information and >>> coordinate their feedback, or should the senders exchange information and >>> coordinate their behavior? => when congestion control mechanisms are split >>> across sender and receiver, the right answer to this question becomes a >>> per-mechanism decision. >>> >>> >>> Please amend this list if I'm missing something. Regarding the one PLUS >>> above, here's a critical look at the benefits of reducing feedback **via >>> receiver-side congestion control**: >>> >>> - less feedback means a greater chance for the feedback to be dropped, >>> which translates into a greater chance for undesirable sender behavior >>> - we deal with interactive traffic, in which case a lot of the feedback >>> could hopefully be piggybacked onto payload packets >>> - in some cases there will be other parallel flows (e.g. the data >>> channel in rtcweb) that already give us all the feedback that we need, this >>> is another chance for feedback reduction >>> - receiver-side-congestion-control-based feedback reduction as in RRTCC >>> means to reduce the feedback whenever feedback isn't urgent for the sender. >>> I'd argue that, in fact, we should reduce feedback only when the channel >>> carrying it (the backwards channel) is congested, and that is a generic >>> function, not bound to the sender-side congestion control behavior. >>> >>> >>> So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver >>> Steeg wrote: >>> >>> *** >>> 1- The upstream/return traffic is (generally) assumed to be a precious >>> resource by the RTP community. This is partially due to multicast >>> considerations (which we can mostly ignore here) and partially due to >>> asynchronous networks. Note that the CableTV community has found it >>> necessary to play games with TCP acks in Cable Modems because of upstream >>> bandwidth limitations, even for unicast TCP traffic. This is an ugly hack >>> that I will not defend here, but it is indicative of the problem space. The >>> net-net is that we have to be somewhat conservative in our sending of acks, >>> or we will end up in similar trouble. >>> *** >>> >>> As he states, multicast is out of scope. Plus, I think we should care >>> more about technical reasons than what the RTP community considers to be a >>> precious resource. As for the CableTV example, one can always find examples >>> where people started doing useless things :-) but consider the >>> following: many parallel TCP connections, each sending lots of feedback, >>> work okay for maaaany end users that 1) surf the Internet or (bringing it >>> closer to rtcweb thinking) 2) use P2P applications. And TCP doesn't even >>> do any form of congestion control on ACKs (an RFC exists but noone uses it >>> (so far)). >>> >>> I'm not saying ACKs never cause problems. I'm saying it's probably rare >>> that they do, and reducing their number WHEN they cause trouble is good >>> enough (and, I would argue, a better decision). >>> >>> >>> Let's take a step back and summarize the situation: >>> 1) congestion-control-based-feedback-reduction has at least one >>> significant MINUS (no. 1), probably two >>> 2) the benefits of doing it seem minimal >>> 3) not being based on congestion along the backwards path, it misses the >>> point somewhat... >>> >>> >>> As a result of the above, I would suggest to move all congestion control >>> functionality to the sender side and keep the receiver side dumb, as in >>> TCP, but amended with some generic (i.e. not mechanism-specific) >>> feedback-reduction functions (ACK congestion control; piggybacking; >>> omitting feedback when it is known (e.g. via a signal from the sender) that >>> we get feedback from another flow). >>> >>> Alternatively, we could still remove the MINUS no. 1 above by agreeing >>> on a generic sender behavior. IIRC, in RRTCC, the sender is rather simple - >>> it follows the rate dictated by the receiver and has a timeout behavior. If >>> all congestion control mechanisms are installed on the receiver side only, >>> with the same agreed generic sender behavior for everyone, we can also have >>> pluggable congestion control without a need for signalling. >>> >> >> I agree that if we go for a receiver-based approach, the sender must be >> dumb. And the other way around if we go for a sender-based approach. >> >> >> Great! Having one side dumb is the most important thing here IMO. >> >> >> >> >>> >>> It's just the idea of multiple proposals for congestion control >>> involving newly described sender AND receiver behavior that strikes me as >>> bad design. >>> >>> Thoughts? >>> >> >> One benefit I see with having the intelligence at the sender is if you >> want to do something more clever when probing the channel, which would >> require coordination between the sender and the one who's supposed to come >> to some conclusion from the incoming packets. I think Bill Ver Steeg >> touched upon something along those lines: >> >> "Basic senders will simply tell the receiver to gather the data every N >> seconds and send it every N seconds (plus when there are problems, as >> defined by the specification). More sophisticated senders could drive more >> complex relationships, asking the receiver to tabulate/send the data on >> demand in semi-real time. This would allow a sophisticated sender to send a >> varying data patterns and get the feedback they require, yet not require >> too much shared state between the sender and receiver. As long as the >> receiver is a simple state machine, I think we would be OK." >> >> >> That method actually just becomes another entry in the list of >> feedback-reduction mechanisms that we already have. >> >> Here's an updated summary: >> >> 1) I have argued that reducing feedback really isn't all that important. >> 2) Say, we want to do it (still a good thing, I think). >> .. a) Then we can and should, first of all, do it based on congestion on >> the backward path. >> .. b) Additionally, it might be possible to reduce feedback because it >> can be piggybacked onto payload (as most scenarios would have traffic >> flowing both ways). >> .. c) Additionally, it might be possible to exploit feedback from other >> parallel flows (e.g., the data channel in rtcweb) >> .. d) Additionally, we can do what is written above, let the sender tell >> the receiver how much feedback it needs. >> > > Yes, however, if we have a feedback message per packet the sender will > always have all the feedback it needs. What I was thinking of was that if > the implementation wants to do something clever by sending packets in some > pattern, knowledge about that clever thing must be available both at the > sender and the receiver if we limit the feedback to, for instance, a > bitrate. > > If we add a way for the sender to ask for more feedback then that would > allow for the sender to do this kind of cleverness also in the > receiver-based approach. And it doesn't have to be decided in advance what > that cleverness is. > > > Maybe I'm not fully getting your idea, but somehow this all sounds like > making things unnecessarily complicated. Knowing whether the congestion > control mechanism requires more feedback or not seems to me to miss the > problem that we're trying to solve. > What I was trying to say is that doing something clever at the sender is easy as long as the sender has per-packet feedback. It gets more involved if you have limited feedback, but it would still be possible if you could increase the amount of feedback for the packets sent in a clever way. > > What's the point of reducing feedback when there's no congestion on the > backward path anyway? The less feedback we send, the more risk of a message > being lost due to whatever reason (congestion appearing, link noise, ...), > and the more fragile the whole thing becomes. I would therefore argue for > sending tons of feedback when we can, and only reduce when we must. And > then, in the face of backwards congestion, we really MUST - the data > congestion control mechanism (I say "data" to distinguish from ACK > congestion control) will just have to cope with it. So it's probably not > even useful to know how much feedback we ideally need... > > Cheers, > Michael > > --14dae9340ae9eace6904ca723dce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 24, 2012 at 2:56 PM, Michael= Welzl <michawe@ifi.uio.no> wrote:

On= 24. sep. 2012, at 14:06, Stefan Holmer wrote:



On Mon, Sep 24, 2012 at 10:40 AM,= Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Sorry, this answ= er is almost ridiculously late...
I compensate by being the first= one to send a technical discussion message to the new list =A0:-)


On 21. sep. 2012, at 16:20, Stefan Holmer= wrote:


O= n Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl <michawe@ifi.uio.no>= wrote:
Hi,

Sorry for bringing this up yet again - but my thoughts just keep returning = to the question of sender-vs.-receiver based congestion control, because it= 's a seemingly simple problem for which we should be able to agree on a= clear answer?!

As most of you probably know by now, I'm critical of a receiver-based a= pproach as in RRTCC. (In fact, as I will explain further below, I argue aga= inst a *combined* sender+receiver approach). Here is a plus/minus list as I= see it:


PLUS no. 1: it helps to reduce the amount of feedback. That's really th= e ONLY benefit.

It also has a small ben= efit in that it can more easily make use of new signals as they are introdu= ced, without having to modify the feedback message, but I guess that argume= nt is a bit hypothetical.

Yes, I'd say that's hypothe= tical =A0:-) =A0 because at the end of the day, there's only so much yo= u can measure... has a packet made it or not, and how long did it take. I a= rgue for giving all of that information to the sender if we go for a sender= -based approach.

=A0

MINUS no. 1: it requires the same mechanism on the sender and receiver side= , which means that, if RTP becomes a "framework" for congestion c= ontrol mechanisms, we must signal which mechanism is used to the other side= . In contrast, we don't have to do this with TCP's (implemented but= not standardized) pluggable congestion control. This is, to me, the bigges= t problem, as it requires code updates to happen on both sides for a new me= chanism to be deployed.

MINUS no. 2: it could make combined congestion control between multiple flo= ws via the FSE more complicated. Anyway it seems we'll need an FSE on t= he sender AND receiver side, but with receiver-based congestion control, we= 'll face the question: for two flows between the same two hosts, sharin= g the same bottleneck, should the receivers exchange information and coordi= nate their feedback, or should the senders exchange information and coordin= ate their behavior? =A0=3D> when congestion control mechanisms are split= across sender and receiver, the right answer to this question becomes a pe= r-mechanism decision.


Please amend this list if I'm missing something. Regarding the one PLUS= above, here's a critical look at the benefits of reducing feedback **v= ia receiver-side congestion control**:

- less feedback means a greater chance for the feedback to be dropped, whic= h translates into a greater chance for undesirable sender behavior
- we deal with interactive traffic, in which case a lot of the feedback cou= ld hopefully be piggybacked onto payload packets
- in some cases there will be other parallel flows (e.g. the data channel i= n rtcweb) that already give us all the feedback that we need, this is anoth= er chance for feedback reduction
- receiver-side-congestion-control-based feedback reduction as in RRTCC mea= ns to reduce the feedback whenever feedback isn't urgent for the sender= . I'd argue that, in fact, we should reduce feedback only when the chan= nel carrying it (the backwards channel) is congested, and that is a generic= function, not bound to the sender-side congestion control behavior.


So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver Ste= eg wrote:

***
1- The upstream/return traffic is (generally) assumed to be a precious reso= urce by the RTP community. This is partially due to multicast consideration= s (which we can mostly ignore here) and partially due to asynchronous netwo= rks. Note that the CableTV community has found it necessary to play games w= ith TCP acks in Cable Modems because of upstream bandwidth limitations, eve= n for unicast TCP traffic. This is an ugly hack that I will not defend here= , but it is indicative of the problem space. The net-net is that we have to= be somewhat conservative in our sending of acks, or we will end up in simi= lar trouble.
***

As he states, multicast is out of scope. Plus, I think we should care more = about technical reasons than what the RTP community considers to be a preci= ous resource. As for the CableTV example, one can always find examples wher= e people started doing useless things =A0:-) =A0 but consider the following= : many parallel TCP connections, each sending lots of feedback, work okay f= or maaaany end users that 1) surf the Internet or (bringing it closer to rt= cweb thinking) =A02) use P2P applications. And TCP doesn't even do any = form of congestion control on ACKs (an RFC exists but noone uses it (so far= )).

I'm not saying ACKs never cause problems. I'm saying it's proba= bly rare that they do, and reducing their number WHEN they cause trouble is= good enough (and, I would argue, a better decision).


Let's take a step back and summarize the situation:
1) congestion-control-based-feedback-reduction has at least one significant= MINUS (no. 1), probably two
2) the benefits of doing it seem minimal
3) not being based on congestion along the backwards path, it misses the po= int somewhat...


As a result of the above, I would suggest to move all congestion control fu= nctionality to the sender side and keep the receiver side dumb, as in TCP, = but amended with some generic (i.e. not mechanism-specific) feedback-reduct= ion functions (ACK congestion control; piggybacking; omitting feedback when= it is known (e.g. via a signal from the sender) that we get feedback from = another flow).

Alternatively, we could still remove the MINUS no. 1 above by agreeing on a= generic sender behavior. IIRC, in RRTCC, the sender is rather simple - it = follows the rate dictated by the receiver and has a timeout behavior. If al= l congestion control mechanisms are installed on the receiver side only, wi= th the same agreed generic sender behavior for everyone, we can also have p= luggable congestion control without a need for signalling.

I agree that if we go for a receiver-based= approach, the sender must be dumb. And the other way around if we go for a= sender-based approach.

Great!= Having one side dumb is the most important thing here IMO.


=A0

It's just the idea of multiple proposals for congestion control involvi= ng newly described sender AND receiver behavior that strikes me as bad desi= gn.

Thoughts?

One benefit I see with having= the intelligence at the sender is if you want to do something more clever = when probing the channel, which would require coordination between the send= er and the one who's supposed to come to some conclusion from the incom= ing packets. I think Bill Ver Steeg touched upon something along those line= s:

"Basic senders will simply tell the receiver = to gather the data every N seconds and send it every N seconds (plus when t= here are problems, as defined by the specification). More sophisticated sen= ders could drive more complex relationships, asking the receiver to tabulat= e/send the data on demand in semi-real time. This would allow a sophisticat= ed sender to send a varying data patterns and get the feedback they require= , yet not require too much shared state between the sender and receiver. As= long as the receiver is a simple state machine, I think we would be OK.&qu= ot;

That method actually just beco= mes another entry in the list of feedback-reduction mechanisms that we alre= ady have.

Here's an updated summary:

1) I have argued that reducing feedback really isn'= t all that important.
2) Say, we want to do it (still a good thin= g, I think).
.. a) Then we can and should, first of all, do it ba= sed on congestion on the backward path.
.. b) Additionally, it might be possible to reduce feedback because it= can be piggybacked onto payload (as most scenarios would have traffic flow= ing both ways).
.. c) Additionally, it might be possible to explo= it feedback from other parallel flows (e.g., the data channel in rtcweb)
.. d) Additionally, we can do what is written above, let the sender te= ll the receiver how much feedback it needs.

Yes, however, if we have a feedback message per pa= cket the sender will always have all the feedback it needs. What I was thin= king of was that if the implementation wants to do something clever by send= ing packets in some pattern, knowledge about that clever thing must be avai= lable both at the sender and the receiver if we limit the feedback to, for = instance, a bitrate.

If we add a way for the sender to ask for more feedback= then that would allow for the sender to do this kind of cleverness also in= the receiver-based approach. And it doesn't have to be decided in adva= nce what that cleverness is.

Maybe I'm not fully getti= ng your idea, but somehow this all sounds like making things unnecessarily = complicated. Knowing whether the congestion control mechanism requires more= feedback or not seems to me to miss the problem that we're trying to s= olve.

What I was trying to say is that doi= ng something clever at the sender is easy as long as the sender has per-pac= ket feedback. It gets more involved if you have limited feedback, but it wo= uld still be possible if you could increase the amount of feedback for the = packets sent in a clever way.
=A0

What's the point of reducing feedback when th= ere's no congestion on the backward path anyway? The less feedback we s= end, the more risk of a message being lost due to whatever reason (congesti= on appearing, link noise, ...), and the more fragile the whole thing become= s.=A0I would therefore argue for sending tons of feedback when we can, and = only reduce when we must. And then, in the face of backwards congestion, we= really MUST - the data congestion control mechanism (I say "data"= ; to distinguish from ACK congestion control) will just have to cope with i= t. So it's probably not even useful to know how much feedback we ideall= y need...

Cheers,
Michael


--14dae9340ae9eace6904ca723dce-- From michawe@ifi.uio.no Mon Sep 24 06:15:30 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A1521F8679 for ; Mon, 24 Sep 2012 06:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-jCkuN6Ti+b for ; Mon, 24 Sep 2012 06:15:29 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 7072F21F845A for ; Mon, 24 Sep 2012 06:15:28 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TG8VT-0005Jt-Co; Mon, 24 Sep 2012 15:15:27 +0200 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 1TG8VS-0000tl-A0; Mon, 24 Sep 2012 15:15:27 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_F952CFA6-3FC2-4C2F-B5FF-42F3BA184A27" From: Michael Welzl In-Reply-To: Date: Mon, 24 Sep 2012 15:15:20 +0200 Message-Id: References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <392AA42E-3BFA-4991-B0E9-FA30F276E7D2@ifi.uio.no> To: Stefan Holmer X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 9 sum msgs/h 5 total rcpts 24014 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.7, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.75, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FACF4729E02F51320B82178ED8A0F5246380B020 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -56 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9674 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 13:15:30 -0000 --Apple-Mail=_F952CFA6-3FC2-4C2F-B5FF-42F3BA184A27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 24. sep. 2012, at 15:05, Stefan Holmer wrote: >=20 >=20 > On Mon, Sep 24, 2012 at 2:56 PM, Michael Welzl = wrote: >=20 > On 24. sep. 2012, at 14:06, Stefan Holmer wrote: >=20 >>=20 >>=20 >> On Mon, Sep 24, 2012 at 10:40 AM, Michael Welzl = wrote: >> Hi, >>=20 >> Sorry, this answer is almost ridiculously late... >> I compensate by being the first one to send a technical discussion = message to the new list :-) >>=20 >>=20 >> On 21. sep. 2012, at 16:20, Stefan Holmer wrote: >>=20 >>>=20 >>> On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl = wrote: >>> Hi, >>>=20 >>> Sorry for bringing this up yet again - but my thoughts just keep = returning to the question of sender-vs.-receiver based congestion = control, because it's a seemingly simple problem for which we should be = able to agree on a clear answer?! >>>=20 >>> As most of you probably know by now, I'm critical of a = receiver-based approach as in RRTCC. (In fact, as I will explain further = below, I argue against a *combined* sender+receiver approach). Here is a = plus/minus list as I see it: >>>=20 >>>=20 >>> PLUS no. 1: it helps to reduce the amount of feedback. That's really = the ONLY benefit. >>>=20 >>> It also has a small benefit in that it can more easily make use of = new signals as they are introduced, without having to modify the = feedback message, but I guess that argument is a bit hypothetical. >>=20 >> Yes, I'd say that's hypothetical :-) because at the end of the = day, there's only so much you can measure... has a packet made it or = not, and how long did it take. I argue for giving all of that = information to the sender if we go for a sender-based approach. >>=20 >> =20 >>>=20 >>> MINUS no. 1: it requires the same mechanism on the sender and = receiver side, which means that, if RTP becomes a "framework" for = congestion control mechanisms, we must signal which mechanism is used to = the other side. In contrast, we don't have to do this with TCP's = (implemented but not standardized) pluggable congestion control. This = is, to me, the biggest problem, as it requires code updates to happen on = both sides for a new mechanism to be deployed. >>>=20 >>> MINUS no. 2: it could make combined congestion control between = multiple flows via the FSE more complicated. Anyway it seems we'll need = an FSE on the sender AND receiver side, but with receiver-based = congestion control, we'll face the question: for two flows between the = same two hosts, sharing the same bottleneck, should the receivers = exchange information and coordinate their feedback, or should the = senders exchange information and coordinate their behavior? =3D> when = congestion control mechanisms are split across sender and receiver, the = right answer to this question becomes a per-mechanism decision. >>>=20 >>>=20 >>> Please amend this list if I'm missing something. Regarding the one = PLUS above, here's a critical look at the benefits of reducing feedback = **via receiver-side congestion control**: >>>=20 >>> - less feedback means a greater chance for the feedback to be = dropped, which translates into a greater chance for undesirable sender = behavior >>> - we deal with interactive traffic, in which case a lot of the = feedback could hopefully be piggybacked onto payload packets >>> - in some cases there will be other parallel flows (e.g. the data = channel in rtcweb) that already give us all the feedback that we need, = this is another chance for feedback reduction >>> - receiver-side-congestion-control-based feedback reduction as in = RRTCC means to reduce the feedback whenever feedback isn't urgent for = the sender. I'd argue that, in fact, we should reduce feedback only when = the channel carrying it (the backwards channel) is congested, and that = is a generic function, not bound to the sender-side congestion control = behavior. >>>=20 >>>=20 >>> So how urgent is it to reduce feedback, anyway? Some time ago, Bill = Ver Steeg wrote: >>>=20 >>> *** >>> 1- The upstream/return traffic is (generally) assumed to be a = precious resource by the RTP community. This is partially due to = multicast considerations (which we can mostly ignore here) and partially = due to asynchronous networks. Note that the CableTV community has found = it necessary to play games with TCP acks in Cable Modems because of = upstream bandwidth limitations, even for unicast TCP traffic. This is an = ugly hack that I will not defend here, but it is indicative of the = problem space. The net-net is that we have to be somewhat conservative = in our sending of acks, or we will end up in similar trouble. >>> *** >>>=20 >>> As he states, multicast is out of scope. Plus, I think we should = care more about technical reasons than what the RTP community considers = to be a precious resource. As for the CableTV example, one can always = find examples where people started doing useless things :-) but = consider the following: many parallel TCP connections, each sending lots = of feedback, work okay for maaaany end users that 1) surf the Internet = or (bringing it closer to rtcweb thinking) 2) use P2P applications. And = TCP doesn't even do any form of congestion control on ACKs (an RFC = exists but noone uses it (so far)). >>>=20 >>> I'm not saying ACKs never cause problems. I'm saying it's probably = rare that they do, and reducing their number WHEN they cause trouble is = good enough (and, I would argue, a better decision). >>>=20 >>>=20 >>> Let's take a step back and summarize the situation: >>> 1) congestion-control-based-feedback-reduction has at least one = significant MINUS (no. 1), probably two >>> 2) the benefits of doing it seem minimal >>> 3) not being based on congestion along the backwards path, it misses = the point somewhat... >>>=20 >>>=20 >>> As a result of the above, I would suggest to move all congestion = control functionality to the sender side and keep the receiver side = dumb, as in TCP, but amended with some generic (i.e. not = mechanism-specific) feedback-reduction functions (ACK congestion = control; piggybacking; omitting feedback when it is known (e.g. via a = signal from the sender) that we get feedback from another flow). >>>=20 >>> Alternatively, we could still remove the MINUS no. 1 above by = agreeing on a generic sender behavior. IIRC, in RRTCC, the sender is = rather simple - it follows the rate dictated by the receiver and has a = timeout behavior. If all congestion control mechanisms are installed on = the receiver side only, with the same agreed generic sender behavior for = everyone, we can also have pluggable congestion control without a need = for signalling. >>>=20 >>> I agree that if we go for a receiver-based approach, the sender must = be dumb. And the other way around if we go for a sender-based approach. >>=20 >> Great! Having one side dumb is the most important thing here IMO. >>=20 >>=20 >>> =20 >>>=20 >>> It's just the idea of multiple proposals for congestion control = involving newly described sender AND receiver behavior that strikes me = as bad design. >>>=20 >>> Thoughts? >>>=20 >>> One benefit I see with having the intelligence at the sender is if = you want to do something more clever when probing the channel, which = would require coordination between the sender and the one who's supposed = to come to some conclusion from the incoming packets. I think Bill Ver = Steeg touched upon something along those lines: >>>=20 >>> "Basic senders will simply tell the receiver to gather the data = every N seconds and send it every N seconds (plus when there are = problems, as defined by the specification). More sophisticated senders = could drive more complex relationships, asking the receiver to = tabulate/send the data on demand in semi-real time. This would allow a = sophisticated sender to send a varying data patterns and get the = feedback they require, yet not require too much shared state between the = sender and receiver. As long as the receiver is a simple state machine, = I think we would be OK." >>=20 >> That method actually just becomes another entry in the list of = feedback-reduction mechanisms that we already have. >>=20 >> Here's an updated summary: >>=20 >> 1) I have argued that reducing feedback really isn't all that = important. >> 2) Say, we want to do it (still a good thing, I think). >> .. a) Then we can and should, first of all, do it based on congestion = on the backward path. >> .. b) Additionally, it might be possible to reduce feedback because = it can be piggybacked onto payload (as most scenarios would have traffic = flowing both ways). >> .. c) Additionally, it might be possible to exploit feedback from = other parallel flows (e.g., the data channel in rtcweb) >> .. d) Additionally, we can do what is written above, let the sender = tell the receiver how much feedback it needs. >>=20 >> Yes, however, if we have a feedback message per packet the sender = will always have all the feedback it needs. What I was thinking of was = that if the implementation wants to do something clever by sending = packets in some pattern, knowledge about that clever thing must be = available both at the sender and the receiver if we limit the feedback = to, for instance, a bitrate. >>=20 >> If we add a way for the sender to ask for more feedback then that = would allow for the sender to do this kind of cleverness also in the = receiver-based approach. And it doesn't have to be decided in advance = what that cleverness is. >=20 > Maybe I'm not fully getting your idea, but somehow this all sounds = like making things unnecessarily complicated. Knowing whether the = congestion control mechanism requires more feedback or not seems to me = to miss the problem that we're trying to solve. >=20 > What I was trying to say is that doing something clever at the sender = is easy as long as the sender has per-packet feedback. It gets more = involved if you have limited feedback, but it would still be possible if = you could increase the amount of feedback for the packets sent in a = clever way. Ah. Sure. Agreed --Apple-Mail=_F952CFA6-3FC2-4C2F-B5FF-42F3BA184A27 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 24. sep. 2012, at 15:05, Stefan Holmer wrote:



On Mon, Sep 24, 2012 at 2:56 PM, Michael Welzl <michawe@ifi.uio.no> wrote:

On 24. sep. 2012, at 14:06, Stefan Holmer wrote:



On Mon, Sep 24, 2012 at 10:40 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Sorry, this answer is almost ridiculously late...
I compensate by being the first one to send a technical discussion message to the new list  :-)


On 21. sep. 2012, at 16:20, Stefan Holmer wrote:


On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Sorry for bringing this up yet again - but my thoughts just keep returning to the question of sender-vs.-receiver based congestion control, because it's a seemingly simple problem for which we should be able to agree on a clear answer?!

As most of you probably know by now, I'm critical of a receiver-based approach as in RRTCC. (In fact, as I will explain further below, I argue against a *combined* sender+receiver approach). Here is a plus/minus list as I see it:


PLUS no. 1: it helps to reduce the amount of feedback. That's really the ONLY benefit.

It also has a small benefit in that it can more easily make use of new signals as they are introduced, without having to modify the feedback message, but I guess that argument is a bit hypothetical.

Yes, I'd say that's hypothetical  :-)   because at the end of the day, there's only so much you can measure... has a packet made it or not, and how long did it take. I argue for giving all of that information to the sender if we go for a sender-based approach.

 

MINUS no. 1: it requires the same mechanism on the sender and receiver side, which means that, if RTP becomes a "framework" for congestion control mechanisms, we must signal which mechanism is used to the other side. In contrast, we don't have to do this with TCP's (implemented but not standardized) pluggable congestion control. This is, to me, the biggest problem, as it requires code updates to happen on both sides for a new mechanism to be deployed.

MINUS no. 2: it could make combined congestion control between multiple flows via the FSE more complicated. Anyway it seems we'll need an FSE on the sender AND receiver side, but with receiver-based congestion control, we'll face the question: for two flows between the same two hosts, sharing the same bottleneck, should the receivers exchange information and coordinate their feedback, or should the senders exchange information and coordinate their behavior?  => when congestion control mechanisms are split across sender and receiver, the right answer to this question becomes a per-mechanism decision.


Please amend this list if I'm missing something. Regarding the one PLUS above, here's a critical look at the benefits of reducing feedback **via receiver-side congestion control**:

- less feedback means a greater chance for the feedback to be dropped, which translates into a greater chance for undesirable sender behavior
- we deal with interactive traffic, in which case a lot of the feedback could hopefully be piggybacked onto payload packets
- in some cases there will be other parallel flows (e.g. the data channel in rtcweb) that already give us all the feedback that we need, this is another chance for feedback reduction
- receiver-side-congestion-control-based feedback reduction as in RRTCC means to reduce the feedback whenever feedback isn't urgent for the sender. I'd argue that, in fact, we should reduce feedback only when the channel carrying it (the backwards channel) is congested, and that is a generic function, not bound to the sender-side congestion control behavior.


So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver Steeg wrote:

***
1- The upstream/return traffic is (generally) assumed to be a precious resource by the RTP community. This is partially due to multicast considerations (which we can mostly ignore here) and partially due to asynchronous networks. Note that the CableTV community has found it necessary to play games with TCP acks in Cable Modems because of upstream bandwidth limitations, even for unicast TCP traffic. This is an ugly hack that I will not defend here, but it is indicative of the problem space. The net-net is that we have to be somewhat conservative in our sending of acks, or we will end up in similar trouble.
***

As he states, multicast is out of scope. Plus, I think we should care more about technical reasons than what the RTP community considers to be a precious resource. As for the CableTV example, one can always find examples where people started doing useless things  :-)   but consider the following: many parallel TCP connections, each sending lots of feedback, work okay for maaaany end users that 1) surf the Internet or (bringing it closer to rtcweb thinking)  2) use P2P applications. And TCP doesn't even do any form of congestion control on ACKs (an RFC exists but noone uses it (so far)).

I'm not saying ACKs never cause problems. I'm saying it's probably rare that they do, and reducing their number WHEN they cause trouble is good enough (and, I would argue, a better decision).


Let's take a step back and summarize the situation:
1) congestion-control-based-feedback-reduction has at least one significant MINUS (no. 1), probably two
2) the benefits of doing it seem minimal
3) not being based on congestion along the backwards path, it misses the point somewhat...


As a result of the above, I would suggest to move all congestion control functionality to the sender side and keep the receiver side dumb, as in TCP, but amended with some generic (i.e. not mechanism-specific) feedback-reduction functions (ACK congestion control; piggybacking; omitting feedback when it is known (e.g. via a signal from the sender) that we get feedback from another flow).

Alternatively, we could still remove the MINUS no. 1 above by agreeing on a generic sender behavior. IIRC, in RRTCC, the sender is rather simple - it follows the rate dictated by the receiver and has a timeout behavior. If all congestion control mechanisms are installed on the receiver side only, with the same agreed generic sender behavior for everyone, we can also have pluggable congestion control without a need for signalling.

I agree that if we go for a receiver-based approach, the sender must be dumb. And the other way around if we go for a sender-based approach.

Great! Having one side dumb is the most important thing here IMO.


 

It's just the idea of multiple proposals for congestion control involving newly described sender AND receiver behavior that strikes me as bad design.

Thoughts?

One benefit I see with having the intelligence at the sender is if you want to do something more clever when probing the channel, which would require coordination between the sender and the one who's supposed to come to some conclusion from the incoming packets. I think Bill Ver Steeg touched upon something along those lines:

"Basic senders will simply tell the receiver to gather the data every N seconds and send it every N seconds (plus when there are problems, as defined by the specification). More sophisticated senders could drive more complex relationships, asking the receiver to tabulate/send the data on demand in semi-real time. This would allow a sophisticated sender to send a varying data patterns and get the feedback they require, yet not require too much shared state between the sender and receiver. As long as the receiver is a simple state machine, I think we would be OK."

That method actually just becomes another entry in the list of feedback-reduction mechanisms that we already have.

Here's an updated summary:

1) I have argued that reducing feedback really isn't all that important.
2) Say, we want to do it (still a good thing, I think).
.. a) Then we can and should, first of all, do it based on congestion on the backward path.
.. b) Additionally, it might be possible to reduce feedback because it can be piggybacked onto payload (as most scenarios would have traffic flowing both ways).
.. c) Additionally, it might be possible to exploit feedback from other parallel flows (e.g., the data channel in rtcweb)
.. d) Additionally, we can do what is written above, let the sender tell the receiver how much feedback it needs.

Yes, however, if we have a feedback message per packet the sender will always have all the feedback it needs. What I was thinking of was that if the implementation wants to do something clever by sending packets in some pattern, knowledge about that clever thing must be available both at the sender and the receiver if we limit the feedback to, for instance, a bitrate.

If we add a way for the sender to ask for more feedback then that would allow for the sender to do this kind of cleverness also in the receiver-based approach. And it doesn't have to be decided in advance what that cleverness is.

Maybe I'm not fully getting your idea, but somehow this all sounds like making things unnecessarily complicated. Knowing whether the congestion control mechanism requires more feedback or not seems to me to miss the problem that we're trying to solve.

What I was trying to say is that doing something clever at the sender is easy as long as the sender has per-packet feedback. It gets more involved if you have limited feedback, but it would still be possible if you could increase the amount of feedback for the packets sent in a clever way.

Ah. Sure. Agreed


--Apple-Mail=_F952CFA6-3FC2-4C2F-B5FF-42F3BA184A27-- From randell-ietf@jesup.org Mon Sep 24 08:57:21 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4621F87E2 for ; Mon, 24 Sep 2012 08:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBnaL4NRJ2gK for ; Mon, 24 Sep 2012 08:57:20 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64421F87DF for ; Mon, 24 Sep 2012 08:57:19 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TGB26-0007b2-OK; Mon, 24 Sep 2012 10:57:18 -0500 Message-ID: <50608290.5020601@jesup.org> Date: Mon, 24 Sep 2012 11:56:00 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtp-congestion@alvestrand.no, rmcat WG References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> In-Reply-To: <5060725F.4090709@alvestrand.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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rmcat WG 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, 24 Sep 2012 15:57:21 -0000 Moving this sub-thread of discussion to the new list... On 9/24/2012 10:46 AM, Harald Alvestrand wrote: > On 09/19/2012 02:26 PM, Michael Welzl wrote: >> Hi, >> >> Sorry for bringing this up yet again - but my thoughts just keep >> returning to the question of sender-vs.-receiver based congestion >> control, because it's a seemingly simple problem for which we should >> be able to agree on a clear answer?! >> >> As most of you probably know by now, I'm critical of a receiver-based >> approach as in RRTCC. (In fact, as I will explain further below, I >> argue against a *combined* sender+receiver approach). Here is a >> plus/minus list as I see it: >> >> >> PLUS no. 1: it helps to reduce the amount of feedback. That's really >> the ONLY benefit. >> >> MINUS no. 1: it requires the same mechanism on the sender and >> receiver side, which means that, if RTP becomes a "framework" for >> congestion control mechanisms, we must signal which mechanism is used >> to the other side. In contrast, we don't have to do this with TCP's >> (implemented but not standardized) pluggable congestion control. This >> is, to me, the biggest problem, as it requires code updates to happen >> on both sides for a new mechanism to be deployed. > I don't see the logic here. The requirement is that both sides send > signals that are responded to appropriately by the other side. So the > two sides' mechanisms have to be compatible (in the RRTCC case, the > demand is that the sender responds to REMB or TMMBR messages - this is > hardly the "same mechanism" as the Kalman filter implemented on the > receiver side). > > In the TCP case, the feedback mechanism is the ack, which is needed > for reasons beyond congestion control. In the RTP case, there isn't > such a single, simple mechanism needed for other reasons. Agreed, though Michael indicated that we can piggyback congestion info on reverse traffic. This may be possible and I've thought about it. Part of the problem is that if you want to signal data back quickly, you have to wait up to 20ms and in some cases longer to piggyback (and on low-upstream-bandwidth links, the uplink transit time if you're piggybacking on a 1500-byte video packet might be 20+ms). If you do piggyback, it has to be optional on a instance-by-instance basis (perhaps even estimating when the next chance will be, and the priority of the data - but that speaks against a dumb receiver). TCP can "get away" with high packet count feedback because flows are typically largely unidirectional or alternating flows, or on well-connected devices, not edge nodes. The PacketCable/etc issue with shared upstreams and slot allocation is an example of reacting to this - there even with the typically largely downstream flows, the upstream acks become a limiting factor. >> >> MINUS no. 2: it could make combined congestion control between >> multiple flows via the FSE more complicated. Anyway it seems we'll >> need an FSE on the sender AND receiver side, but with receiver-based >> congestion control, we'll face the question: for two flows between >> the same two hosts, sharing the same bottleneck, should the receivers >> exchange information and coordinate their feedback, or should the >> senders exchange information and coordinate their behavior? => when >> congestion control mechanisms are split across sender and receiver, >> the right answer to this question becomes a per-mechanism decision. > FSE? > I don't see the logic here either. Either the two flows are under a > common controller on one side, they're under a common controlller on > the other side, they're not under any common controller, or they are > under common controllers on both sides. All four cases can happen with > both sender side and receiver side implementations of the BWE > computation. >> >> >> Please amend this list if I'm missing something. Regarding the one >> PLUS above, here's a critical look at the benefits of reducing >> feedback **via receiver-side congestion control**: >> >> - less feedback means a greater chance for the feedback to be >> dropped, which translates into a greater chance for undesirable >> sender behavior > Stickler: Amount of feedback has little correlation with packet drop. > If feedback is lost due to congestion, more feedback will lead to more > packet drops. What is true is that when feedback occurs more rarely, > losing one feedback packet will lead to a greater gap between feedback > packets. I'd say less feedback means the odds that a drop will hit a feedback packet are *lower* (as routers typically either tail-drop or random-drop, but in either case in a static evaluation a lower-bandwidth/packet flow (i.e. the feedback packets) will get hit less often), but as Harald says the impact is higher. And in a dynamic evaluation this may shift some. >> - we deal with interactive traffic, in which case a lot of the >> feedback could hopefully be piggybacked onto payload packets See above. This may not be that useful in practice, or may degrade congestion response time. >> - in some cases there will be other parallel flows (e.g. the data >> channel in rtcweb) that already give us all the feedback that we >> need, this is another chance for feedback reduction Do not count on the data channel being active or substituting for media-channel feedback even if active. It may provide another source of feedback data. >> - receiver-side-congestion-control-based feedback reduction as in >> RRTCC means to reduce the feedback whenever feedback isn't urgent for >> the sender. I'd argue that, in fact, we should reduce feedback only >> when the channel carrying it (the backwards channel) is congested, >> and that is a generic function, not bound to the sender-side >> congestion control behavior. Personally, I assume both channels are always congested, or will be soon (if we're doing our job right and aren't on a huge link), so bandwidth reduction for feedback always allows more bandwidth for useful data. In fact, this is one of the better arguments for piggybacking - less bandwidth required to provide the same bandwidth, but at the cost of the feedback possibly being delayed (and in some cases perhaps more likely to be impacted if the drops are packet-size aware, not just packet-aware, or if they get piggybacked on a packet with a lower DSCP marking). >> >> >> So how urgent is it to reduce feedback, anyway? Some time ago, Bill >> Ver Steeg wrote: >> >> *** >> 1- The upstream/return traffic is (generally) assumed to be a >> precious resource by the RTP community. This is partially due to >> multicast considerations (which we can mostly ignore here) and >> partially due to asynchronous networks. Note that the CableTV >> community has found it necessary to play games with TCP acks in Cable >> Modems because of upstream bandwidth limitations, even for unicast >> TCP traffic. This is an ugly hack that I will not defend here, but it >> is indicative of the problem space. The net-net is that we have to be >> somewhat conservative in our sending of acks, or we will end up in >> similar trouble. >> *** > I asusme "asynchronous" is "asymmetric" above? >> >> As he states, multicast is out of scope. Plus, I think we should care >> more about technical reasons than what the RTP community considers to >> be a precious resource. As for the CableTV example, one can always >> find examples where people started doing useless things :-) but >> consider the following: many parallel TCP connections, each sending >> lots of feedback, work okay for maaaany end users that 1) surf the >> Internet or (bringing it closer to rtcweb thinking) 2) use P2P >> applications. And TCP doesn't even do any form of congestion control >> on ACKs (an RFC exists but noone uses it (so far)). >> >> I'm not saying ACKs never cause problems. I'm saying it's probably >> rare that they do, and reducing their number WHEN they cause trouble >> is good enough (and, I would argue, a better decision). >> And my position is that any *good* two-way communication will run near-but-not-quite-over the bandwidth limit as much of the time as possible, so ACKs always have the potential to cause problems (and always will force you a little further down the quality curve). >> >> Let's take a step back and summarize the situation: >> 1) congestion-control-based-feedback-reduction has at least one >> significant MINUS (no. 1), probably two > Both are debatable. >> 2) the benefits of doing it seem minimal >> 3) not being based on congestion along the backwards path, it misses >> the point somewhat... > What that bullet was meant to say totally escaped me. RRTCC is all > about congestion on the forward path, not the backwards path. and in addition, per above, one should assume back-path congestion anyways. >> >> As a result of the above, I would suggest to move all congestion >> control functionality to the sender side and keep the receiver side >> dumb, as in TCP, but amended with some generic (i.e. not >> mechanism-specific) feedback-reduction functions (ACK congestion >> control; piggybacking; omitting feedback when it is known (e.g. via a >> signal from the sender) that we get feedback from another flow). >> >> Alternatively, we could still remove the MINUS no. 1 above by >> agreeing on a generic sender behavior. IIRC, in RRTCC, the sender is >> rather simple - it follows the rate dictated by the receiver and has >> a timeout behavior. If all congestion control mechanisms are >> installed on the receiver side only, with the same agreed generic >> sender behavior for everyone, we can also have pluggable congestion >> control without a need for signalling. Correct. >> >> It's just the idea of multiple proposals for congestion control >> involving newly described sender AND receiver behavior that strikes >> me as bad design. I think if the sender (or receiver) have a simple design that can be interacted with by the (more complex) main algorithm would allow for improvement without requiring negotiation (and allow for asymmetric behaviors by different implementations/revisions or even asymmetry due to local network knowledge (wifi, etc). >> >> Thoughts? > As you can see, I tend to disagree with the validity of your arguments. > You may still be right, but you're not convincing me with this set of > arguments. > (Another conversation I had last week was with one guy who argued that > we should use a traceroute-like functionality to directly probe queues > near the sender, rather than depending on whole-RTT signalling - that > kind of mechanism would rely on packets that didn't even reach the > receiver. Now, if we explore *that*, it's a real argument for putting > control at the sender....) Such probing may be problematic... if you can determine local and nearby network configuration, that might be useful. In my old algorithm, I used a heuristic of establishing max-known-good-bandwidth early in the call, and then being very cautious at "dipping my toes over" the (likely upstream) limit. (If it did remain delay-stable for long enough after going over, I'd update the limit.) Obviously this heuristic is more useful in leaf-node cases, but this provided some of what I think that person may have been thinking about. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Sep 24 09:18:01 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5990921F8466 for ; Mon, 24 Sep 2012 09:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS3ckpr6a03A for ; Mon, 24 Sep 2012 09:18:00 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E621F87E6 for ; Mon, 24 Sep 2012 09:18:00 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TGBM6-0000NW-OT; Mon, 24 Sep 2012 11:17:59 -0500 Message-ID: <50608768.6070306@jesup.org> Date: Mon, 24 Sep 2012 12:16:40 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtp-congestion@alvestrand.no, rmcat WG References: <20120905214652.11822.49183.idtracker@ietfa.amsl.com> <201209191430.31628.mirja.kuehlewind@ikr.uni-stuttgart.de> <5059E924.5070702@mti-systems.com> <201209192223.46541.mkuehle@ikr.uni-stuttgart.de> <250F3784-6A59-4A25-9A3C-59A88E186FBE@ifi.uio.no> In-Reply-To: <250F3784-6A59-4A25-9A3C-59A88E186FBE@ifi.uio.no> 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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rmcat] [R-C] WG Review: RTP Media Congestion Avoidance Techniques (rmcat) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rmcat WG 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, 24 Sep 2012 16:18:01 -0000 Moving discussion to RMCAT... On 9/20/2012 3:02 AM, Michael Welzl wrote: > On 19. sep. 2012, at 22:23, Mirja Kühlewind wrote: > >> Hi, >> >>>> provide further explanations here: >>>>> - Develop a mechanism for identifying shared bottlenecks between >>>>> groups of flows, and means to flexibly allocate their rates within the >>>>> aggregate hitting the shared bottleneck. >>> The original motivation for this was pretty simple. If you knew two >>> flows with different elasticities were sharing a bottleneck, and seeing >>> loss, you could make the congestion reaction on the more elastic flow, >>> and leave the less elastic one untouched. >> Okay, I can understand this point. But if fact if you see congestion and you >> are elastic (up to a certain degree), you should lower your sending rate (or >> do whatever you can do) because there also might be other flows on the link >> that need the bandwidth even more urgent. > With combined congestion control, this (lowering the send rate) will happen. Consider having only one controller; then, "making the congestion reaction on the more elastic flow" translates into a change to the scheduler that takes data from application 1 and application 2 in addition to the standard congestion control reaction for what looks like one flow to the network. You can also proportionally allocate the reduction, etc. This just allows for more direct interaction, potentially less 'hunting' and less chance of corner-case behaviors, and faster reaction (most algorithms, especially delay-sensing algorithms) need some number of inputs to ensure a datapoint isn't jitter or an outlier (i.e. filtering the data). More data points from parallel flows should lead to better/faster reaction time. > > (in fact, the way I envision it, this behavior would be the result of information exchange between multiple controllers). > > >> I guess the only case I really see is if there is not enough bandwidth for >> both transmissions (such that both of the respective services do not work >> proper) and you have to decide which one to kill. But that's the >> circuit-breaker case and thus out of scope. > This sounds like a misunderstanding. I hope what I wrote above and my previous email help. Else, maybe you'd want to take a look into the list archives for more information; this has been discussed at some depth in the past. BTW, Randell Jesup has, at some point, stated that Mozilla is already using such scheduling / combined congestion control. Already planning to use; not yet implemented. -- Randell Jesup randell-ietf@jesup.org From michawe@ifi.uio.no Wed Sep 26 04:29:14 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A9821F87F2 for ; Wed, 26 Sep 2012 04:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgASbSzoo5Nz for ; Wed, 26 Sep 2012 04:29:12 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 61D9A21F87ED for ; Wed, 26 Sep 2012 04:29:12 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TGpni-0003K8-Ur for rmcat@ietf.org; Wed, 26 Sep 2012 13:29:10 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.198]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TGpnh-0005oY-Qr for rmcat@ietf.org; Wed, 26 Sep 2012 13:29:10 +0200 Message-Id: <9BE23689-DFA9-4CA9-87CB-F82C7A2DC565@ifi.uio.no> From: Michael Welzl To: rmcat WG In-Reply-To: <50608290.5020601@jesup.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Sep 2012 13:28:46 +0200 References: <9DB4BEBD-8C49-443D-8C7D-4787EF314453@ifi.uio.no> <5060725F.4090709@alvestrand.no> <50608290.5020601@jesup.org> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 24045 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FAB934BB8E55EF67E5BFCDA9B8C78B1913EF9840 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1459 max/h 15 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rmcat] [R-C] Sender- vs. receiver-based, yet again... X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2012 11:29:14 -0000 Hi, (new list only) On Sep 24, 2012, at 5:56 PM, Randell Jesup wrote: > Moving this sub-thread of discussion to the new list... > > On 9/24/2012 10:46 AM, Harald Alvestrand wrote: >> On 09/19/2012 02:26 PM, Michael Welzl wrote: >>> Hi, >>> >>> Sorry for bringing this up yet again - but my thoughts just keep >>> returning to the question of sender-vs.-receiver based congestion >>> control, because it's a seemingly simple problem for which we >>> should be able to agree on a clear answer?! >>> >>> As most of you probably know by now, I'm critical of a receiver- >>> based approach as in RRTCC. (In fact, as I will explain further >>> below, I argue against a *combined* sender+receiver approach). >>> Here is a plus/minus list as I see it: >>> >>> >>> PLUS no. 1: it helps to reduce the amount of feedback. That's >>> really the ONLY benefit. >>> >>> MINUS no. 1: it requires the same mechanism on the sender and >>> receiver side, which means that, if RTP becomes a "framework" for >>> congestion control mechanisms, we must signal which mechanism is >>> used to the other side. In contrast, we don't have to do this with >>> TCP's (implemented but not standardized) pluggable congestion >>> control. This is, to me, the biggest problem, as it requires code >>> updates to happen on both sides for a new mechanism to be deployed. >> I don't see the logic here. The requirement is that both sides send >> signals that are responded to appropriately by the other side. So >> the two sides' mechanisms have to be compatible (in the RRTCC case, >> the demand is that the sender responds to REMB or TMMBR messages - >> this is hardly the "same mechanism" as the Kalman filter >> implemented on the receiver side). >> >> In the TCP case, the feedback mechanism is the ack, which is needed >> for reasons beyond congestion control. In the RTP case, there isn't >> such a single, simple mechanism needed for other reasons. What are these other reasons? I see why TCP's ACKs wouldn't do, but I don't see why a similarly simple generic feedback mechanism wouldn't. (sure, that won't work if we have RRTCC with a Kalman filter vs. ABC with a CDE filter vs. .... but my argument is that this is bad design for exactly that reason) > Agreed, though Michael indicated that we can piggyback congestion > info on reverse traffic. > > This may be possible and I've thought about it. Part of the problem > is that if you want to signal data back quickly, you have to wait up > to 20ms and in some cases longer to piggyback (and on low-upstream- > bandwidth links, the uplink transit time if you're piggybacking on a > 1500-byte video packet might be 20+ms). If you do piggyback, it has > to be optional on a instance-by-instance basis (perhaps even > estimating when the next chance will be, and the priority of the > data - but that speaks against a dumb receiver). Ok, I agree with that. > TCP can "get away" with high packet count feedback because flows are > typically largely unidirectional or alternating flows, or on well- > connected devices, not edge nodes. The PacketCable/etc issue with > shared upstreams and slot allocation is an example of reacting to > this - there even with the typically largely downstream flows, the > upstream acks become a limiting factor. I can see that, too. >>> MINUS no. 2: it could make combined congestion control between >>> multiple flows via the FSE more complicated. Anyway it seems we'll >>> need an FSE on the sender AND receiver side, but with receiver- >>> based congestion control, we'll face the question: for two flows >>> between the same two hosts, sharing the same bottleneck, should >>> the receivers exchange information and coordinate their feedback, >>> or should the senders exchange information and coordinate their >>> behavior? => when congestion control mechanisms are split across >>> sender and receiver, the right answer to this question becomes a >>> per-mechanism decision. >> FSE? Sorry - I meant Flow State Exchange, my idea for how combined congestion control should be done, as described here: http://www.alvestrand.no/pipermail/rtp-congestion/2012-July/000436.html It doesn't matter. For what we're discussing here, it's fine to think of a single common controller. >> I don't see the logic here either. Either the two flows are under a >> common controller on one side, they're under a common controlller >> on the other side, they're not under any common controller, or they >> are under common controllers on both sides. All four cases can >> happen with both sender side and receiver side implementations of >> the BWE computation. So, I think we had some agreement already that there need to be common controllers on both sides. ( On the sender side, N out of M flows may share a bottleneck, and on the receiver side, X out of Y flows may share a bottleneck. ) The common control has to interact with, as you say, the BWE computation, which one mechanism could do on the sender side and another could do on the receiver side, and hence I said it's mechanism- specific. I just think we should agree to have it on one side only - ok with me if it's the receiver, dealing with a relatively dumb generic sender. >>> Please amend this list if I'm missing something. Regarding the one >>> PLUS above, here's a critical look at the benefits of reducing >>> feedback **via receiver-side congestion control**: >>> >>> - less feedback means a greater chance for the feedback to be >>> dropped, which translates into a greater chance for undesirable >>> sender behavior >> Stickler: Amount of feedback has little correlation with packet >> drop. If feedback is lost due to congestion, more feedback will >> lead to more packet drops. What is true is that when feedback >> occurs more rarely, losing one feedback packet will lead to a >> greater gap between feedback packets. > > I'd say less feedback means the odds that a drop will hit a feedback > packet are *lower* (as routers typically either tail-drop or random- > drop, but in either case in a static evaluation a lower-bandwidth/ > packet flow (i.e. the feedback packets) will get hit less often), > but as Harald says the impact is higher. And in a dynamic > evaluation this may shift some. Sorry sorry! I was thinking TCP, where there is some redundancy in ACKs. Indeed I meant the same as what Harald wrote - IF something is lost, the impact is higher. To correct my own phrasing, I meant: less feedback means a greater chances that some important piece of information never reaches the sender. >>> - we deal with interactive traffic, in which case a lot of the >>> feedback could hopefully be piggybacked onto payload packets > > See above. This may not be that useful in practice, or may degrade > congestion response time. Ok, but as you say it depends. I think we should allow that, optionally. >>> - in some cases there will be other parallel flows (e.g. the data >>> channel in rtcweb) that already give us all the feedback that we >>> need, this is another chance for feedback reduction > > Do not count on the data channel being active or substituting for > media-channel feedback even if active. It may provide another > source of feedback data. Sure, that's all I meant. It might be there, and might then help reduce the feedback further. >>> - receiver-side-congestion-control-based feedback reduction as in >>> RRTCC means to reduce the feedback whenever feedback isn't urgent >>> for the sender. I'd argue that, in fact, we should reduce feedback >>> only when the channel carrying it (the backwards channel) is >>> congested, and that is a generic function, not bound to the sender- >>> side congestion control behavior. > > Personally, I assume both channels are always congested, or will be > soon (if we're doing our job right and aren't on a huge link), so > bandwidth reduction for feedback always allows more bandwidth for > useful data. In fact, this is one of the better arguments for > piggybacking - less bandwidth required to provide the same > bandwidth, but at the cost of the feedback possibly being delayed > (and in some cases perhaps more likely to be impacted if the drops > are packet-size aware, not just packet-aware, or if they get > piggybacked on a packet with a lower DSCP marking). Ok, I think you got me convinced. The way I see it, there's a choice between: 1) sending a lot of feedback, and only reducing it when there is backwards congestion, by doing congestion control on the backwards channel like ACK-CC 2) simply always sending as little feedback as possible, based on the (forward) congestion control mechanism's requirements If we think of e.g. a videoconference, indeed congestion from all the feedback on the uplink is quite realistic. 1) can then become rather complicated... you may get congestion on your uplink, and it might be necessary to reduce the rate of your data stream, or it might suffice to reduce it on some of the feedback streams, but which? And then we have to apply priorities between feedback packets and your payload... 2) seems simpler, but it has the problem of making the mechanism more fragile, and perhaps unnecessarily so (in a situation where it might be fine to send much more feedback). I say "unnecessarily" because I'm not convinced about "both channels are always congested, or will be soon" because codecs may not be greedy, and streams such as VoIP may simply not generate enough traffic for that. Anyway, putting these pro's and con's together, yes, I think I'm now convinced that receiver-side congestion control is the better solution, mainly because it makes things easier, and the disadvantages aren't huge. I still think that we should consider making things less fragile by sending more feedback only when there is very clearly no backwards congestion, which could be done by backing off immediately at the slightest indication of increasing delay on the backward path (up to the point of what the minimum rate is, as determined by the receiver). But this could be an optional later add-on to a receiver- side mechanism such as RRTCC. >>> So how urgent is it to reduce feedback, anyway? Some time ago, >>> Bill Ver Steeg wrote: >>> >>> *** >>> 1- The upstream/return traffic is (generally) assumed to be a >>> precious resource by the RTP community. This is partially due to >>> multicast considerations (which we can mostly ignore here) and >>> partially due to asynchronous networks. Note that the CableTV >>> community has found it necessary to play games with TCP acks in >>> Cable Modems because of upstream bandwidth limitations, even for >>> unicast TCP traffic. This is an ugly hack that I will not defend >>> here, but it is indicative of the problem space. The net-net is >>> that we have to be somewhat conservative in our sending of acks, >>> or we will end up in similar trouble. >>> *** >> I asusme "asynchronous" is "asymmetric" above? Yes, I assume the same. >>> As he states, multicast is out of scope. Plus, I think we should >>> care more about technical reasons than what the RTP community >>> considers to be a precious resource. As for the CableTV example, >>> one can always find examples where people started doing useless >>> things :-) but consider the following: many parallel TCP >>> connections, each sending lots of feedback, work okay for maaaany >>> end users that 1) surf the Internet or (bringing it closer to >>> rtcweb thinking) 2) use P2P applications. And TCP doesn't even do >>> any form of congestion control on ACKs (an RFC exists but noone >>> uses it (so far)). >>> >>> I'm not saying ACKs never cause problems. I'm saying it's probably >>> rare that they do, and reducing their number WHEN they cause >>> trouble is good enough (and, I would argue, a better decision). >>> > > And my position is that any *good* two-way communication will run > near-but-not-quite-over the bandwidth limit as much of the time as > possible, so ACKs always have the potential to cause problems (and > always will force you a little further down the quality curve). See above: I don't buy that. You can have very good VoIP traffic never doing that. But it doesn't matter, as I did buy your argument about the TCP scenario usually being different. Indeed, if we e.g. think of a video conference, there may be tons of feedback packets from multiple streams on the uplink, while we desperately want to get our video across that same link too. >>> Let's take a step back and summarize the situation: >>> 1) congestion-control-based-feedback-reduction has at least one >>> significant MINUS (no. 1), probably two >> Both are debatable. I agree they are - and indeed, as I wrote above, I see the pro/con weights differently now. >>> 2) the benefits of doing it seem minimal >>> 3) not being based on congestion along the backwards path, it >>> misses the point somewhat... >> What that bullet was meant to say totally escaped me. RRTCC is all >> about congestion on the forward path, not the backwards path. > > and in addition, per above, one should assume back-path congestion > anyways. Yes, and I don't see what was not understandable about that bullet. If you're not concerned about congestion on the backwards path, why reduce the amount of feedback? What else is your concern - processing? >>> As a result of the above, I would suggest to move all congestion >>> control functionality to the sender side and keep the receiver >>> side dumb, as in TCP, but amended with some generic (i.e. not >>> mechanism-specific) feedback-reduction functions (ACK congestion >>> control; piggybacking; omitting feedback when it is known (e.g. >>> via a signal from the sender) that we get feedback from another >>> flow). >>> >>> Alternatively, we could still remove the MINUS no. 1 above by >>> agreeing on a generic sender behavior. IIRC, in RRTCC, the sender >>> is rather simple - it follows the rate dictated by the receiver >>> and has a timeout behavior. If all congestion control mechanisms >>> are installed on the receiver side only, with the same agreed >>> generic sender behavior for everyone, we can also have pluggable >>> congestion control without a need for signalling. > > Correct. Stefan said that too. So I think we already have some agreement here on having a relatively dumb generic sender behavior, and I'm now joining you people in thinking that the per-mechanism intelligence is better done on the receiver side. >>> It's just the idea of multiple proposals for congestion control >>> involving newly described sender AND receiver behavior that >>> strikes me as bad design. > > I think if the sender (or receiver) have a simple design that can be > interacted with by the (more complex) main algorithm would allow for > improvement without requiring negotiation (and allow for asymmetric > behaviors by different implementations/revisions or even asymmetry > due to local network knowledge (wifi, etc). Yes. The sender, it seems. >>> Thoughts? >> As you can see, I tend to disagree with the validity of your >> arguments. >> You may still be right, but you're not convincing me with this set >> of arguments. >> (Another conversation I had last week was with one guy who argued >> that we should use a traceroute-like functionality to directly >> probe queues near the sender, rather than depending on whole-RTT >> signalling - that kind of mechanism would rely on packets that >> didn't even reach the receiver. Now, if we explore *that*, it's a >> real argument for putting control at the sender....) > > Such probing may be problematic... if you can determine local and > nearby network configuration, that might be useful. In my old > algorithm, I used a heuristic of establishing max-known-good- > bandwidth early in the call, and then being very cautious at > "dipping my toes over" the (likely upstream) limit. (If it did > remain delay-stable for long enough after going over, I'd update the > limit.) Obviously this heuristic is more useful in leaf-node cases, > but this provided some of what I think that person may have been > thinking about. I like the idea, and I guess the guy was John Leslie, as this idea was a part of his CC-workshop paper: http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper14.pdf ...but this strikes me as VERY researchy - I'd definitely want to see some solid data before believing that this can work (and hence basing rmcat's design decisions on it). There are some unknowns here, including the possible impact of strange behavior of the equipment sending you an ICMP message back. I'd first have to believe that one can trust the timing of these ICMP enough to make any sense of it for a congestion control mechanism. I'd love to see some experimental data presented in ICCRG! Cheers, Michael