From nobody Tue Apr 2 02:03:11 2019 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 59FB1120094; Tue, 2 Apr 2019 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg1f4n8zzHry; Tue, 2 Apr 2019 02:03:07 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8300A1201EF; Tue, 2 Apr 2019 02:03:05 -0700 (PDT) Received: from 200116b82c549500f85205ae131c249f.dip.versatel-1u1.de ([2001:16b8:2c54:9500:f852:5ae:131c:249f]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hBFJp-0005mL-29; Tue, 02 Apr 2019 11:02:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: <20190324135134.GM77890@kduck.mit.edu> Date: Tue, 2 Apr 2019 11:02:56 +0200 Cc: "rmcat-chairs@ietf.org" , Benjamin Kaduk via Datatracker , "draft-ietf-rmcat-eval-test@ietf.org" , "rmcat@ietf.org" , The IESG , Colin Perkins Content-Transfer-Encoding: quoted-printable Message-Id: References: <155197033601.24667.6429871717336324511.idtracker@ietfa.amsl.com> <3C53B15F-9C66-4C64-8C15-A643EADE6B54@ericsson.com> <20190323134227.GZ88959@kduck.mit.edu> <0E1DBC98-6486-483C-8CEA-893BAC4F930E@ericsson.com> <20190324135134.GM77890@kduck.mit.edu> To: Benjamin Kaduk , Zaheduzzaman Sarker X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1554195785;628cfe74; X-HE-SMSGID: 1hBFJp-0005mL-29 Archived-At: Subject: Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 09:03:09 -0000 Hi Zahed, hi Ben, Just a quick note below. > On 24. Mar 2019, at 14:51, Benjamin Kaduk wrote: >=20 >>> Section 3 >>>=20 >>> + Bottleneck-link capacity: defines minimum capacity of = the >>> end-to-end path >>>=20 >>> I'm not sure I'd describe this as the "minimum capacity of the >>> end-to-end path", since attempts to use anything larger than this = value >>> will pile up at the bottleneck. >>>=20 >>> [ZS] hmm, I guess that is why that link will act as bottleneck link = for a respective testcase. If the flows remain below that capacity it = should not experience queuing and as you said anything above that = capacity will observe queuing. The job of the congestion control = algorithm will be to avoid queuing. >>=20 >> I think I was expecting "maximum capacity" to be more appropriate = than >> "minimum capacity". Perhaps I'm confused about what is intended = here. >>=20 >> (disclaimer. this has been done in the long past and I hope my memory = is supporting me on explaining it =E2=98=BA) >>=20 >> The thinking was that the bottleneck-link capacity was not equals to = the maximum link capacity. That means if the maximum link capacity is X = then the bottleneck-link capacity is Y , where Y=20 > Ah, that makes sense. Maybe "minimum guaranteed capacity" or similar = would > convey the intent better. The word =E2=80=9Cguaranteed=E2=80=9D would be confusing here as people = would associate this with some kind of resource reservation. Maybe = "minimum link capacity of the end-to-end path=E2=80=9D. Mirja From nobody Wed Apr 17 05:28:06 2019 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 E5770120457; Wed, 17 Apr 2019 05:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZERZcVRQLj_W; Wed, 17 Apr 2019 05:27:55 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C69120357; Wed, 17 Apr 2019 05:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1540; q=dns/txt; s=iport; t=1555504074; x=1556713674; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Rmft6EH8a1ZI+nhw7PNXRXlBjmyRBWSudicMqG/xzSk=; b=aLyNFjcWVmDpaZsgvKVreLv5QdU1u8Vihqp1mzoRMp6WrWpoxjcIlZOp 9MvRklvPcveUSCq7UD/LB5QpJx3g1hqvN6dlWUGgSr7GCj2hoNrpkjwRn 1HzpBC3rlQ9ATJ6qKCy5K2ydmbYVGLUIeqzb+nafPJfVQlERAx+aTabid g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAABSG7dc/xbLJq1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUgUBAQELAYJ4UQEgEoQ2iHulBIF7ECOLAzUIDgEDAQEEAQIBAm0?= =?us-ascii?q?cDIV0FXYCJgJgDAgBAYMeAYIID6oGgS+EMgGBFIRiBoELJwGEYIcAgUA/gRE?= =?us-ascii?q?nhHJ/GQKEa4JXBIp8h1STbQmCCAKFOFGMDQYbi2aJE4twhi+OH4FQATaBVjM?= =?us-ascii?q?aCBsVgyiCMINMilU9A5EiAQE?= X-IronPort-AV: E=Sophos;i="5.60,361,1549929600"; d="scan'208";a="11390962" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Apr 2019 12:27:50 +0000 Received: from [10.61.95.184] (ams3-vpn-dhcp8121.cisco.com [10.61.95.184]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x3HCRoZM002779; Wed, 17 Apr 2019 12:27:50 GMT To: rmcat@ietf.org, avt@ietf.org From: Sergio Mena Message-ID: Date: Wed, 17 Apr 2019 14:27:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Outbound-SMTP-Client: 10.61.95.184, ams3-vpn-dhcp8121.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [rmcat] Hackathon code for draft-ietf-avtcore-cc-feedback-message X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.29 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, 17 Apr 2019 12:27:57 -0000 Hello, I found some spare time to tidy up the Firefox/WebRTC code we developed during last two IETF hackathons in Bangkok (IETF103) and Prague (IETF104). During last avtcore and rmcat meetings, I perceived some interest in the room on potentially introducing CCFB in WebRTC, hence I am making our code available in case it can be useful. You can find the code in the "ccfb" Git branch of my Firefox repo fork: https://github.com/sergio-mena/gecko-dev/tree/ccfb All our code is between commits 2cd33e4e03ce..dc93b019beb5 A few comments: * The bulk of the code is the result of porting the initial implementation we made for ns3-rmcat, which is our open source simulation testbed for rmcat algorithms: https://github.com/cisco/ns3-rmcat * This branch is mainly the result of the two Hackathons, so don't expect plenty of unit tests. Additionally, there is a known problem whereby each CCFB packet gets deserialized three times. * At the end of the last hackathon we ran successful interop tests with Jonathan Lennox's independent proprietary implementation of CCFB (also coded during the hackathons). * The code has been updated to implement version -03 of the draft. Finally, the Firefox branch we worked on contains a two-year-old version of WebRTC. Unfortunately, a "git rebase" of the branch to the latest Firefox nightly yields many conflicts with WebRTC classes. I will see if I can find some spare time to solve those conflicts after the vacation break. Thanks, Sergio From nobody Sun Apr 28 06:16:08 2019 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 9F66B12003E; Sun, 28 Apr 2019 06:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix862cwTeD33; Sun, 28 Apr 2019 06:15:56 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3091200CC; Sun, 28 Apr 2019 06:15:56 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id h26so6758555ioj.1; Sun, 28 Apr 2019 06:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/IcVpYLZHvheZz/hovsVN6CKrqkz+UXohDfNKzalfq4=; b=R2jfqtO7iLQP9po7d/japovXmmYPfZBRKtkDCjnxyhYzM6wlVbGPPltMY/F/asxSgq HDy+n+m8vCOF6kZl1kI98HCh4GqhndffDbGkePSMVGec8UdW5bF/40K8+72/Jvz7apDA Pip/22p+JTyUDKG8ux94jn2yoPpim6LT0p8FNVDiHuigo/WU/AWZKEIMKuYxnOlfUvPb PMMhuMYEhH66262k0yV7euWlBUdsk3R66hRWljnt+S64OzjJfjAG4OTUT8o/MCneTlZy jcxAOTM1b0oBC/HsCQZ7hMqaovoy8ZifuGp/vQHHF6o7OaNhgie2Q5NFzdDEWOASwcrp UQaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/IcVpYLZHvheZz/hovsVN6CKrqkz+UXohDfNKzalfq4=; b=Cv7L0/zmA6icDNL+eBWntCI45U0Y8BA/dUrcG+EKphaLvVi8FnMrAfCY6csNf13Ajf MjlIaFT0YecfCrY1jFJCDgrCfJqvLa7RgFpHt/0wITD+QEFpI1BeIqWMO9yZcn+lHGNI MBSBtSs23gdN64/3OsxXuWsC9lisbK6mrfcqgM2QjYLRfKyvT1BtYRPoA9bAYm3PACxA UGiin/IYI+G3mmIA/rmsSFhLAp/A0ybfAi+Yt3Na8lh1wtxLc7Hd8FRPsmKpGd/E3R0i sTmninsbxxc/mMevaTEaZqT/7iWqqVjxHXkIS8/4fDyGi9+A01Ug6SbNd98kduyJgPch eKUA== X-Gm-Message-State: APjAAAV/VU435tM6YdE/XVF+fpldT4/AVgYOWJk/hhKnHC8VNBAlon5K //6dEJpDro8x9NehbG7ZU/60BKp3WSUxQ2k8wn8= X-Google-Smtp-Source: APXvYqyA615LkbisQtvppstkt1Q1fLLnFFy/3CmVw7ko0e+H4x3nhcTVER74bZormnoLp1po0oVnPCqgmt3uolbFRiY= X-Received: by 2002:a6b:f809:: with SMTP id o9mr37300915ioh.232.1556457355796; Sun, 28 Apr 2019 06:15:55 -0700 (PDT) MIME-Version: 1.0 From: Dave Taht Date: Sun, 28 Apr 2019 15:15:44 +0200 Message-ID: To: Cake List , tsvwg IETF list , iccrg IRTF list , rmcat@ietf.org, BBR Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rmcat] sch_cake shaper/aqm/fq implementation in linux slides and paper X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 13:15:59 -0000 Since sch_cake has been generally available as dual licensed (BSD/GPL) open source since last august (as of linux 4.19), and shipping in openwrt and evenroute for 3 years, I have generally longed for more folk to be fiddling with it in the ietf. The most current stable version is in openwrt 18.02, which shipped in january. Cake is in general is too complicated and addresses too many things to encapsulate into an RFC, but in particular, the DOCSIS/DSL/Ethernet framing compensation modes are excellent (unlike the BSD pfsense one), and we have many other improvements to multiple components of the SQM systems we've been shipping for 8 years. such as per host/per flow FQ, sane diffserv support, and ack-filtering being theprimary ones covered in slides from my IEEE lanman talk: http://www.taht.net/~d/sch_cake_ieee_lanman2018%20(2).pdf One major feature not brought out in paper or slides is that cake works the same whether it has backpressure from the device or via "BQL", OR in shaping in software. Another important feature - GRO-splitting, we haven't gone into much in print yet. In the extra slides section are some nice results from a GPON fiber network. It can also be used as a local host-only qdisc; there is a brief comparison of cake vs sch_fq also in the slides above. As well as in network namespaces, vms, docker containers, multi-tenant dcs, etc, etc. All the features of cake were developed in close collaboration with the actual users of SQM in the field. That paper: https://arxiv.org/pdf/1804.07617.pdf - talks about "Home" gateways but since then we got it to scale past 50GigE in software alone. I look forward to more independent benchmarkings in other scenarios, and we do take bug reports on the github. Some of the new SCE ("Some Congestion Experienced") related work has landed in the https://github.com/dtaht/sch_cake repo already (as well as fq_codel_fast) but the majority of work is taking place over in jonathan's repos presently. There is a paper pending, also, on the improvements to codel that jonathan (primarily) made in the COBALT AQM that I hope will be published soon. One thing I've longed for is some coherent testing of the modern videoconferencing and quic and bbr congestion control algorithms against it. Is there anyone out there able to do this and possibly collaborate on a paper on it? I was really quite unaware until this past ietf that so few had had a taste of cake yet. thx! --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Tue Apr 30 14:30:46 2019 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 1E5AE12003F for ; Tue, 30 Apr 2019 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matthew-at.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_qThXTYDI60 for ; Tue, 30 Apr 2019 14:30:42 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE748120006 for ; Tue, 30 Apr 2019 14:30:42 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id l2so4567328plt.11 for ; Tue, 30 Apr 2019 14:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matthew-at.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ghCZwyi6mKLwUTVCVVbMZY3UI7WA9o7ROyDAPRlm3dg=; b=APgyIWPKhZbh0P1q8TihDPTSte4ko1he/cQMVfqK13ivREleo/CrDGmO6+XxIB3hPS yQsbSSQFa8zURQdkbQTNTlqche2YXqQETgAkv6dwi5jn0yjM13irO6XSP/Q8TJ+QihdJ nvJcMAEBt++3ITxv2bfE8Gygy43ie4GhXSHchCN2de3oojLFFUI+cfJR7iu8F0wUgCfW wU+yztxMQtSvQzcS0cLGyKrz+CJpTXpHxmlsEC+wPCJkjPKpcqf6amG+86phh5O37ktz yc5PRLpyvI4dWf0e7FUij4xvEsxnA8Ckx/4+f2y8upWQLjUjpnPzl9pWj12aUiKRlaTW VIHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ghCZwyi6mKLwUTVCVVbMZY3UI7WA9o7ROyDAPRlm3dg=; b=lYq1yCk2A6DI7206Al1uDcPUhczxoL3X13DxdrUw/2l4pCylR1OjDh3yFBA4RNXJ6W 5FFBY0YjWGXdXla5dxoiEZZyeVCtyCYnVJ0sgGUsRaks7yvbsBzU/1gMEiJTztqc1Y6I 1x3tj46TUACQohzllskMczvGKntyq3/wwaRFYdL8So6m8oS8FoP/p4xMEDZVF3prHTUt AaDn2Ka78Fya/6wHt1OXf1LFEaGoiNejiqJ5qZkfF9nGG/04JqRibf9JaYARnmxSIaMi Gnft3bVsv4GXq18DX+lquLJP1Kl1l8ZXMlppHAcVl4THPd8+rVTAV1z5PINKeyIVz4MF J+9g== X-Gm-Message-State: APjAAAWxuwBJQ88ISn3+hb8Ktm5eIbpKrB7VSEClwk3DyFL3hk9fVmXX ogU1bxe/j9/1lZNzAt5yBP4GNzhVY6WZZfr5D4chY0tlrAE= X-Google-Smtp-Source: APXvYqw6pQ9Xq9n5JIdJ2csAeOA4eJVa4qdGqoovd+W2iiNBF0Yi4v1mhDmNTD2bEVxgtAWyr1/SRXtvWPTnXgTAE4w= X-Received: by 2002:a17:902:6b47:: with SMTP id g7mr26093590plt.227.1556659842002; Tue, 30 Apr 2019 14:30:42 -0700 (PDT) MIME-Version: 1.0 From: Matthew Kaufman Date: Tue, 30 Apr 2019 14:30:31 -0700 Message-ID: To: rmcat@ietf.org Content-Type: multipart/alternative; boundary="000000000000eb46940587c61c75" Archived-At: Subject: [rmcat] heads-up on plan to break Internet X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:30:45 -0000 --000000000000eb46940587c61c75 Content-Type: text/plain; charset="UTF-8" Every congestion controller has loss-based feedback, whether it is the primary mechanism (e.g., TCP Reno) or a backup that enforces a maximum rate as loss increases above threshold (e.g., Google's algorithm that ignores loss rates between 2 and 10 percent but cuts aggressively above 10% loss). Sadly, there are more and more video conferencing system evaluations taking place with simulated networks that are incompatible with this feedback mechanism... specifically, I'm seeing customers running multi-vendor tests over simulated impaired networks with fixed packet loss rates (irrespective of utilized bandwidth) of 10%, 15%, and even higher. In order to "win" these trials, it seems prudent to simply ignore loss altogether and/or detect fixed consistent loss as "detected benchmarking" and disable the loss feedback in that case. So, this is just a heads-up that my implementations are heading that way, and others are headed that way too (if they haven't already). Feedback welcome. Matthew Kaufman --000000000000eb46940587c61c75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Every congestion controller has loss-based feedback, wheth= er it is the primary mechanism (e.g., TCP Reno) or a backup that enforces a= maximum rate as loss increases above threshold (e.g., Google's algorit= hm that ignores loss rates between 2 and 10 percent but cuts aggressively a= bove 10% loss).

Sadly, there are more and more video con= ferencing system evaluations taking place with simulated networks that are = incompatible with this feedback mechanism... specifically, I'm seeing c= ustomers running multi-vendor tests over simulated impaired networks with f= ixed packet loss rates (irrespective of utilized bandwidth) of 10%, 15%, an= d even higher.

In order to "win" these t= rials, it seems prudent to simply ignore loss altogether and/or detect fixe= d consistent loss as "detected benchmarking" and disable the loss= feedback in that case.

So, this is just a heads-u= p that my implementations are heading that way, and others are headed that = way too (if they haven't already).

Feedback we= lcome.

Matthew Kaufman
--000000000000eb46940587c61c75--